But try using raw and timezone-zero as I suggested. If both can’t handle it, it’s deep mess.
Works like this. so that is messed up as this is the first time i get this error .
Xojo can’t handle dates that doesn’t exist for your Time Zone. All dates contain an hour component and is set to 00:00:00, for your locale date 1992-03-29 00:00:00 doesn’t exist, that’s why you get an error.
There are a couple of bug reports already there:
71555 - DateTime FromString fails for “1974-12-22” if the TimeZone on the computer is set to Uruguay
72471 - DateTime.FromString raises InvalidArgumentException for a valid date string
In your case, you can try fromstring using 01:00:00 for the time part.
Or just changing the timezone used in the conversion as the time will be discarded.
d = DateTime.FromString(s , Locale.Raw, New TimeZone(0))
that is insane and i see the issue was reported 1 year ago in some cases and still not fixed
The solution is known.
What crashed there?
NSTimeZone *timezone = [NSTimeZone timeZoneWithName:timeZoneName];
NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
[dateFormatter setDateFormat:@"yyyy-MM-dd'T'HH:mm:ss"];
[dateFormatter setTimeZone:timezone];
NSDate *date = [dateFormatter dateFromString:scheduledDateTime];
What they did to solve?
NSTimeZone *timezone = [NSTimeZone timeZoneWithName:timeZoneName];
NSISO8601DateFormatter *dateFormatter = [[NSISO8601DateFormatter alloc] init];
[dateFormatter setTimeZone:timezone];
dateFormatter.formatOptions = NSISO8601DateFormatWithFractionalSeconds | NSISO8601DateFormatWithInternetDateTime;
NSDate *date = [dateFormatter dateFromString:scheduledDateTime];
People had similar issues and fixed it using ISO8601 options doing fractional calculations in seconds
dateFormatter.formatOptions = NSISO8601DateFormatWithFractionalSeconds | NSISO8601DateFormatWithInternetDateTime
That was informed, but ignored until now?
apparently yes , the bug is still there , or at least on the ones Alberto pointed, i don’t see them marked as fixed #66499, #72471 and i guess many others
Add thumbs up to this:
done, apparently loosing data is not important as they are delayed. so when your business is dealing with data , not fun.
1 Like
They will need this info from your locale to replicate the case using the date 1992-03-29 :
Show us what you got if possible:
Var t As TimeZone = TimeZone.Current
MessageBox Locale.Current.Identifier + " TZ "+ _
t.Abbreviation + " GMT" + t.SecondsFromGMT.ToString
Here I see
But I wasn’t affected.
1 Like
en_RO TZ Europe/Bucharest GMT10800
1 Like
For your time zone, all the ‘clock forward’ dates that happen at midnight will fail, for example:
it looks like since 1997 the jump forward is at 3am, so no problems there.
1 Like
What I don’t understand is that this workaround SHOULD not crash for zero hour, fixed date, unless after getting the correct value some internal math occurs using his locale info.
I can’t find where it was said that this crash. I even see that the code is selected as the answer for this topic. Did you do some tests and it crash?
If It throws an exception and it’s not handled, it’ll crash.
So far this does not crash and yes, i do add that in a throw/catch and handle the error and it passes.
the previous one was crashing
Var d As Datetime
Var s As String = "1992-03-29"
s = s.DefineEncoding(Encodings.ASCII)
d = DateTime.FromString(s)
break
Let’s put the communication clear.
So, for handling fixed dates, ignoring the time part if it was set using current locale/TZ (it will be considered GMT+0 ), this workaround is OK:
Var d As Datetime
// This DateTime currently crashes for locale/TZ en_RO Europe/Bucharest GMT+10800
Var s As String = "1992-03-29" // Same as "1992-03-29 00:00:00"
// d = DateTime.FromString(s) ' <<-- Crashes in Bucharest, RO.
// Workaround. Force simple POSIX TZ GMT+00:00 ::: to ignore the time part
d = DateTime.FromString(s , Locale.Raw, New TimeZone(0))
1 Like