Does anyone know how ParseDate and DateTime.FromString decide how to handle date strings with a 2-digit year? And if there’s any way of telling them to handle them differently?
For example, with US date format, parsing “01/01/49” returns “01/01/2049”, whereas parsing “01/01/50” returns “01/01/1950”. Depending on the context, it would be useful to tell these methods whether to assume the date is in the future or in the past. e.g. when dealing with a birthday you’d probably want to assume it’s in the past, in other contexts a future date might be more likely.
That is interesting, apparently I get few complaints as well from our customers that patients around that age get parsed as 2049. It would be nice to Get a point of view from XOJO side.
Ideally, I’d like to be able to supply context to help those methods decide how to interpret 2-digit dates so that we can deal with situations like the one you describe without breaking it in other contexts.
Well the funny part in my case is that they are in the format SQL Date stored so that should not be an issue but I see some times the date as you said instead of taking it as 1942 customers mentioned that it takes it as 2042 so making my customers -22 years old . . I guess I’ll have to dig more into this , but so far I’m stuck with XOJO 2019 R3.2 so if there was a fix on the newer IDE then I guess I cannot do much. Apparently from what feedback I got , all that are born before 1950 get this bug.
At least in a persons age a negative value is obviously wrong and easily spotted.
I write astronomical programs and do everything with dates as Julian date, in seconds. Simple formula to convert to a double to YYYMMDD.HHMMSS and vice versa, I use the method by Jan Meeus. I won’t use the Xojo methods at all anymore, because it’s not readily apparent just from a position computed for an astro object whether Xojo has screwed up in some way, the locale or the timezone is off, or daylight saving is/isn’t applied for the location. And the consequence is the app isn’t just off by a little bit, they’re hopelessly wrong.
The only way to find out is to pull out a telescope and look up to verify the calculation. Users are understandably annoyed if the app is wrong.
Agreed. The Xojo methods are not robust enough. I wrote a textfield subclass that handles dates quite well. I don’t use a popup, just keyboard input with some shortcuts built in. Such as “20” is interpreted as 2021-06-20. “05-20” is 2021-05-20, etc. It supports both 2-digit and 4-digit years. For birth dates, I require the full 4 digit year. My clients appreciate having the confidence that the year will not be misinterpreted.
Thanks, Markus: I missed that part of my testing out of my original post, but it would still be helpful to be able to tell the method whether it should assume whether a 2-digit date is in the future or the past depending on context.
If the passed date string uses two digits for the year, ParseDate on macOS assumes the current century.
And this warning about Windows:
On Windows (due to the Windows API being used), it is not possible to go back further than 1 January 1601.
Does this mean that the details of how ParseDate and DateTime.FromString handle 2-digit years are left to the operating system and so outside of Xojo’s control?
Personally, I avoid 2-digit years, but some countries do seem to prefer them and it’s the round trip between displaying a date stored as YYYY-MM-DD using ShortDate in the UI and converting it back to YYYY-MM-DD for storage after editing where I occasionally run into problems. ParseDate and DateTime.FromString do a great job of handling all of the localisation settings that could cause headaches, but being able to give them the context to know whether a date is more likely to be in the future or past would help here.
. I guess I’ll have to dig more into this , but so far I’m stuck with XOJO 2019 R3.2 so if there was a fix on the newer IDE then I guess I cannot do much. Apparently from what feedback I got , all that are born before 1950 get this bug.