Private Declare Function SetLocaleInfo Lib "kernel32" Alias "SetLocaleInfoA" (ByVal Locale As Long, ByVal LCType As Long, ByVal lpLCData As String) As Boolean
Public Declare Function GetSystemDefaultLCID Lib "kernel32" () As Long
Private Declare Function GetLocaleInfo Lib "kernel32" Alias "GetLocaleInfoA" (ByVal Locale As Long, ByVal LCType As Long, ByVal lpLCData As String, ByVal cchData As Long) As Long
These are older VB6 declares but if you google their usage, you'll see that it is possible to obtain the result you want. It, unfortunately, is not an easy task. If you can encapsulate your date forms to use a format that you will expect - in other words, the form will use the DD-MM-YYYY format, then you can predict the outcome but you will need to avoid using any of the standardized date formats given by Microsoft.
It isn't just the date that is a problem:
Dim Separator As String * 1
Separator = Mid$(Trim$(Format$(3 / 2)), 2, 1)
You also have the issue of the decimal but that is easily solved by using the above.
A Julian date using a double, will handle any date anyone throws at you to the nearest second but as you drill down below seconds, it can become problematic also. If you go to GEDCOM, you can see that the time for migration from Gregorian calendars to the current day calendars took place between 1583 (something like that) and as late as the early 1900's for other countries, so if you are looking for times prior to 1900, it can get complicated if you are doing anything historical.
Nevertheless, you can use the get and set locale to change the information but if your program crashes while it is set to the wrong region, your customer won't like you. I'd advise doing it within some sort of try catch for each call so that no matter what happens, the region they have set will be reverted to whether the calculation from the date succeeds or fails.
R, J