How does DateTime handle DaylightSavings?

General
21

Someone will need to try replicate to the detail to know.

Your said “a code working” was

Dim dd As DateTime = DateTime.Now()
MessageBox dd.ToString

With your computer set to YOUR LOCALE but changed your time zone in your computer settings to his (if I understood correctly).

And his code was

Dim tz As New TimeZone("America/Mexico_City")
Dim dd As DateTime = DateTime.Now(tz)

msgbox dd.tostring

With his computer set to HIS LOCALE and using Now(tz) instead of Now()

Surely you guys are not comparing oranges to oranges yet.

22

We can’t, as I’m using mac and Jose is using Windows 11. We need:

  • Jose to confirm if he manually changed the DST settings on Windows 11, or other setting
  • someone with Windows 11

Changed my mac computer to Mexico City TZ and executed this code:

Dim dd As DateTime = DateTime.Now()
System.DebugLog dd.ToString

Dim tz As New TimeZone("America/Mexico_City")
Dim dd2 As DateTime = DateTime.Now(tz)
System.DebugLog dd2.ToString

Resutl:

8:11:27 AM : Jun 18, 2023 at 8:11:27 AM
             Jun 18, 2023 at 8:11:27 AM

my local time was 9:11 but the computer set it to Mexico City time.

23

That’s the worst-case scenario. Mac has its own set of DateTime bugs related to DST / leap years as you can see here:

https://tracker.xojo.com/xojoinc/xojo/-/issues/72471

24

I think you know that that case has nothing to do with what Jose is experimenting.

That case is happening because Xojo can’t handle a nonexistent time during a Daylight change. In the US and other countries the changes are done at 2am or 3am, where the bug exists the change is at 0hrs so a DateTime of YYYY-MM-DD 00:00:00 does not exist and Xojo report that as invalid. I hope they fix that but again has nothing to do with Jose’s problem.

Is fine if you don’t want to try to replicate what Jose is experimenting, but just posting other bugs here does not help anyone.

25

I’m not comparing cases 1:1, I’m just saying that now you are in an extra layer of differences (that has known bugs too) for the comparison.

26

and yet you complain that we are not comparing oranges to oranges.

When I have time I will download a Windows 11 VM and test there to see if I can reproduce what Jose is seeing. I hope I can post useful information then.

If you have access to Windows 11 (or maybe even do a test with Windows 10) can you try to replicate Jose’s problem?

1 Like
27

No time for that. If want to replicate his case you can use a Window 11 VM on your mac.

28

this is what I said:

today is Father’s day, we have plans so I’m not sure if I will do it today.

Thanks

1 Like
29

Both codes end up with the same WRONG result.

If you manually adjust the result of a buggy function, your code could break anytime.

API 2 is not production ready, you can still use the “deprecated” Date class

image

30

Thank you Ivan, I assume you are able to reproduce the problem using Windows.

Are you creating an Issue for this?

31

Not really, is kind of frustrating to see your Issues hanging there for months or Years. I will just stick to api 1. Feel free to create the issue if you need the fix.

32

DateTime uses the ICU library and as I remember it, if the version that Xojo is using is not aware of this change, it won’t be applied correctly. I suspect that Xojo will need to update their version of the ICU library to correct this problem.

33

Issue created:
#73143 - DateTime for Mexico still gives DST in Windows even when the hour change was removed

1 Like
34

Very plausible. As such Mexico change is very new, last October/2022.
Xojo ICU update must be done ASAP, in all releases, due to such dynamic nature of locales, time zones, language rules, date/time, currencies, etc.

After October ICU reached ICU v73 (march release). Stable with 2 minor updates. v73.2.

Since October lots of other world changes occurred too, those minor changes handle small fixes and updating those changes.

Update to the latest ICU v73.2 is extremely advisable.

Next planned version is v74.0 for October/2023.

1 Like