I am seeing a strange error from the DateTime.FromString. My app crashes on the following statement
dt = DateTime.FromString( “2024-03-10 02:04” )
However, if I change the statement to
dt = DateTime.FromString( “2024-03-11 02:04” )
Code works fine I can reproduce this at will. My app is discovering dates from a device log and this feature has worked fine for more than a year. Now all of a sudden this happens.
Correct I have not set it and for many records (1000’s) not an issue. The statement above is successful yet a I get a run time exception on the 03-10 date.
DateTime.FromString can’t handle not valid times. As 03/10/2024 is the day when the clock changes 1 hour at 2 am, 2:04 does not exist.
Are you using Xojo2024r1? One of the Issues reported says fixed for that version.
Edit: the fix only handle Dates without time and some Time Zones. The error still present for “03/10/2024 02:04” for a date/time that is between the ‘jump’ from regular time to daylight saving time.
the daylight change in october occurs the last sunday of october, and the last sunday of march
sorry but the 10th of march is not the last sunday, nor is the 3rd october.
there is something else.
Var d As DateTime
Var tz As new TimeZone("Europe/Rome")
Var lc As new Locale("it-IT")
// The crash is Locale related
d = DateTime.FromString("2024-05-10 02:04", Nil, tz) // This works in BR
break
d = DateTime.FromString("2024-05-10 02:04", lc, tz) // This crashes
break
I encountered this last night, finally nailed it! Let me make sure my issue was same as yours…
I receive a time, it’s GMT, but it’s in text that looks like this {“utc”: “2024-04-24 12:00:00”}
My issue: No matter what I did to try to create a DateTime object from this, it kept creating/coverting it to PST (my timezone), and converting it to UTC/GMT via the constructor that takes “secondsFrom1970 As [Double], timeZone As [TimeZone] = [Nil]”
All I was after was a way to make a DateTime, from a string, that represents that string as UTC/GMT.
Here’s what I ended up doing (and it works wherever the function is running and doesn’t impose a local timeZone):
Var WO_SERVICE_START_UTC_inherited_timezone As DateTime = DateTime.FromString(wo_service_start.Value("utc").StringValue)
Var YYYY As Integer = WO_SERVICE_START_UTC_inherited_timezone.Year
Var MO As Integer = WO_SERVICE_START_UTC_inherited_timezone.Month
Var DD As Integer = WO_SERVICE_START_UTC_inherited_timezone.Day
Var HR As Integer = WO_SERVICE_START_UTC_inherited_timezone.Hour
Var MN As Integer = WO_SERVICE_START_UTC_inherited_timezone.Minute
Var WO_SERVICE_START_UTC As DateTime = New DateTime(YYYY, MO, DD, HR, MN, 0, 0, New TimeZone("UTC"))
Each country is different. USA changed on March 10, 2024 at 2am ‘jumped’ to 3am.
Do the test for your current timezone and date change, you need to use Hours/Minutes between the non-existing hour. So if on your timezone the change is the last Sunday of March and it jumps from 2am to 3am, then try:
var dt as datetime
dt = DateTime.FromString( "2024-03-31 02:04" )
and see the exception.
Note: make sure the time is between the ‘jump’. This only happens at ‘jump forward’ (there is no 02:04 for that day for example), when you return the clock 1 hour, as the minutes are valid twice, you will not get the exception.
I spend some time on Issues trying to find one that relates to OP problem (having a time during the ‘jump’ ahead for DST) but I can’t find it.
My question:
What do you think Xojo should do if we have a DateTime.FromString with a Date and Time on the non-existing times for a spring forward DST hour change?
I think that instead of giving an Exception the result DateTime should be a time that exists, for example for most USA “2024-03-10 02:04” should give us a DateTime of 03/10/2024 03:04 am. Or at least have a flag to allow the Exception or give us the valid corresponding time (for practical purposes 02:04 is now 03:04 as the original time never existed).
I agree there should not be an exception. However, I am not in agreement that the time 2024-3-10 02:xx is not a valid time. In some time zones that maybe a time that is skipped due to daylight savings. But it is still a valid time as far as the clock goes.
In my example I am collecting app events that are based on GMT due to global app deployment. The simple fact that I DID NOT select the time zone GMT returns an exception is not the best approach. Especially since it is due to specifics of a time zone. This implies I now have to track these time zone specific globally.
The Command should support a nil time zone in that no assumptions or conversion should occur. As long as the time is a valid time by the clock it should work. If a time zone is set, I am on the fence about what should be returned. I am thinking there should be an option to observe situations specific to the time zone if the switch is True. If False return what I put in and certainly not an Exception.
As I indicated earlier, I found a work around I manual striped the information and created a date time. So that I could offset the date to local time. Which actually did NOT occur during the DST transition. And the conversion went fine.
So I would expect DateTime on line 17 fail just like DateTime.FromString on line 21. Hence both should work the same. I do understand the issue about times that don’t exists due to DST. It should be up to the developer how to handle DST or other issues based on policy. So having a switch to control that is my 2 cents.
Someone had asked I am using 2023 R 3.1 on a Mac M2 Pro.
