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 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.
You guys are doing a lot of work that shouldnât need to be done.
Internally, the DateTime class always stores the time as UTC.
The TimeZone is an ± offset from the internal value.
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.
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.
I recently dealt with an issue with daylight saving time, as in Mexico (where I live) it will no longer be used starting this year 2023. It would be great if there was an easy way to turn it off from within Xojo, but there isnât, "IsDaylightSavingsTime " is read-only⊠so I wrote this VERY simple code to subtract an hour from the current time when itâs daylight saving time, using âDateIntervalâ.
// -- Remove one hour from local time (non-DST)
Var d, NotDST as DateTime = DateTime.Now
Var IsDaylightSavingsTime As Boolean
Var di As New DateInterval
di.Hours = 1 // 1 Hour Less because here in Mexico, the DST adds one hour, so I need to reduce time by 1 hour to stay DST-free, you can change this value according to your needs
if d.IsDaylightSavingsTime=True Then
NotDST = DateTime.Now - di // This line reduces 1 hour to the clock, just like that!
Else
NotDST = DateTime.Now
End
// Now you can use the new time DST-free
MsgBox "The non-DST time is : "+NotDST.toString
This solved my problem, so I want to share it with you guys, I hope some of you will find it useful.
Hi AlbertoD, well Iâm using PC/Windows 11. My computer displays the right time, but when I call from Xojo SQLDateTime it always gives me one more hour, itâs very strange!
So if I use:
Var d as DateTime = DateTime.Now
MsgBox d.toString
I get one more hour even if the computerâs time is correct.
If itâs 7:00PM in real life, and computerâs time is 7;00PM, the code gives me 8:00PM
I already tried your code, with the Mexico Cityâs code of course, and I got the same errorâŠ
Dim tz As New TimeZone("America/Mexico_City")
Dim dd As DateTime = DateTime.Now(tz)
msgbox dd.tostring
It displays 8:00PM but the time is 7:00PM
I guess thatâs what happens when youâre out of the norm.
I donât know who came up with the idea of âânot applying DST, we were fine.
Also my Google Nest Hub went crazy, and Google took weeks to fix the bugâŠ
Xojo has DateTime bugs related to Daylight Saving Times found in some locales/tz and another that occurs only in leap years if I do recall well. I think you just found some jackpot combination.
Iâm curious what is the combination. Windows 11 related? Jose changed the system time manually (as manually removed the DST so Xojo is asking the DateTime with DST to the OS)? something else?
