How does DateTime handle DaylightSavings?

I am confused about how the DateTime object handles Daylight Savings Time. The only way that I can figure DateTime could know about this is through the time zone. But Daylight Savings Time can be different in different locations even in the same time zone. For example, Arizona does not do Daylight Savings time, but Colorado does, and both are in the Mountain (UTC-7) time zone.

Also, if I specify that I want to add an interval of, say 5 months, 2 days, and 00:00 hours to that for January 1, 2022 at 00:00 hours, does it give me the final date of May 3 at 00:00, or May 3 at 01:00, since DST is in effect during the final date, but not the initial date? If the latter, again, how does it know whether to apply this DST correction or not?

I have a web app where I have to calculate times over the entire world and display them accurately, so understanding exactly how this works is a real issue! Thanks for any help.

Arizona is Mountain Standard Time (MST) and Colorado is Mountain Daylight Time (MDT). They’re not the same thing. MST is UTC-7 and MDT is UTC-6. People mistakenly refer to both as MST, and that’s where the confusion comes in.

Yes, currently. But in the winter, both are MST (UTC-7). (Here in CA, we informally say that we are in the PST time zone until the spring switch, and then in the PDT time zone until we switch back.)

Or are you saying that if I tell DateTime that Colorado is in the “MDT” time zone, then it will deliver UTC-7 in the winter and UTC-6 in the summer?

If that is what you mean, then how do I handle this for other locations? Is there some kind of time-zone code that DateTime accepts that will specify whether and/or when the time switches anywhere in the world?

I had the same challenge and found the only way to achieve correct calculation of DateTime differences over different time zones and seasons is going through UTC.
Haven’t yet implemented in Xojo, but this is my general workflow:

  • get local time (system)
  • get local date (system)
  • get location (country and administrative subdivision (state/region) if relevant)
  • calculate current offset to UTC DateTime, including DST offset
  • calculate and store UTC DateTime, (store location, too, if relevant)

From this point forward a difference to UTC DateTime (add, subtract) can be calculated and adapted to any location at any local date and time for presentation in the UI.

I did this test with the local time that observes DST:
D1 = Jan 01, 2022 00:00:00 (TZ -21600)
DInterval(0, 5, 2)
D2 = Jun 03, 2022 00:00:00 (TZ -18000)

If your interval is made of hours (0,0,0,3672) then
D2 = Jun 03, 2022 01:00:00 (TZ -18000)

This makes sense because an interval of ‘months’ changes depending on the month you use it (5 months are not the same days if you start in Jan or March) and in normal conversation we say ‘next appointment is en 5 months and 2 days’ and we expect to be the same time. This may not be what you want/need so you will need to code around it.

I guess Xojo ‘asks’ the os about the DST settings. DSTs are changed around the world most years (I see that on my Garmin GPS updates) and I have never seen a Xojo update that mentions DST updates so they must use the underlying os for it to work. If the os has the wrong information about a TZ then the result will be wrong. The only way for you to make it perfect is to create your own conversion tables and update them every year if needed.

Again, this is only my guess on how Xojo works.

You guys are doing a lot of work that shouldn’t need to be done.

  1. Internally, the DateTime class always stores the time as UTC.
  2. The TimeZone is an ± offset from the internal value.
  3. The daylight savings info is a part of the ICU library which contains the offsets, dates of those offsets and if/when they changed over the years.

So when you have a DateTime for a particular date, with a particular TimeZone, it should always be correct.

You can check and see if the current time is or is not daylight savings by checking the IsDaylightSavingsTime property. This will be especially important in the Fall when the clocks are set backward and you could technically have two 1:30am’s. The first where IsDaylightSavingsTime = True and the second an hour later where IsDaylightSavingsTime = False.

3 Likes

Is documented somewhere what version of ICU is used in each release of Xojo?

You’d have to ask Xojo. I don’t work there any more.

Sorry. I didn’t ask you because you worked with Xojo but only if you have seen the ICU version mentioned in the documentation somewhere.

I guess, by your response, you haven’t.

Just for information, the icu*.dll in Xojo 2021r1.1 to 2022r1.1 shows ICU 65.1

That’s pretty old, from 2019/October. Current stable one is 71.1, 2022/April

Thanks to all who have replied. This is very helpful. Now all I need is to find a complete list of all the ICU time-zone designations somewhere. Also, I need a way to link a given city to an ICU time zone designation (the way I used to look up time zones on Wikipedia (which does not yet specify ICU time zones). Any ideas about this? I have been looking but still not finding what I need.

https://docs.oracle.com/cd/E41183_01/DR/ICU_Time_Zones.html

gives a list (not sure how up-to-date it is). But I still need a way to link an arbitrary location to the correct time zone.

Here’s the ICU link: https://unicode-org.github.io/icu/userguide/datetime/timezone/