I’d like a little background information on why the Constructor for Xojo.Core.TimeZone is in seconds rather than hours. It seems odd since I don’t recall any timezones being in increments of less than an hour. Is that not true?
I’m also trying to figure out the point of the 2nd constructor with the TimeZone name. It seems like an odd choice unless we can get the entire list from somewhere.
Yes, TimeZones can certainly be in increments of less than an hour. This is one of the reasons we put so much effort into the new date/time handling- because trying to deal with those manually can be painful. I’m out and about, but see here for quick info on your questions:
[quote=155214:@Travis Hill]Yes, TimeZones can certainly be in increments of less than an hour. This is one of the reasons we put so much effort into the new date/time handling- because trying to deal with those manually can be painful. I’m out and about, but see here for quick info on your questions:
Code dealing with time & time zones should be clearly marked “There be dragons here”
It’s OK when everything is in one time zone and it really starts to suck big time when they are in different timezones & maybe observe daylight savings on different schedules (like Canada & the US used to) and have screwy offsets (like 1/2 DST adjustments).
The spring move to DST isn’t so bad since you just have a gap where times don’t exist (thats fun) - basically you jump from 1 AM to 2AM but the reversion back may have 2 occurrences of 1:30 AM since you fall from 2AM back to 1AM.
So, when dealing with storing a DateTime in a database, it seems like it would be beneficial to store the TimeZone then. But, since the equivalent SQLDateTime doesn’t do that, what is the recommended practice? Store the datetime AND the TimeZone data in separate fields? This may result in a much bigger answer than appropriate for now but each database might be a bit different.
Is there any sort of timeframe for having the Database classes recognize the new Date class? The only way to insert and update right now is do it via native SQL insert/update statements.
Several database systems won’t appropriately store the timezone- MySQL for example just straight up says to convert everything to GMT for storage. There’s unfortunately no magic we can do to make every DB store timezone information along with datetime values. So storing as GMT is still the recommended practice when it comes to databases- it allows people to query the data easily outside of your app, and it allows compatibility across every database.
My experience is that GMT is the only way date/time should be stored. Time zone independence is especially important when copying or moving data to servers in different countries. When being reported or displayed, that’s the time to do the local conversion.
That is a great video and oh so true! There are many places where Daylight Savings time is not recognized even within a country that otherwise does follow it. Here in the USA, there are some states that do not change their clocks. In the Mountain timezone, which covers the western great plains and Rocky Mountain states, Arizona ignores Daylight Savings time - except for some Native American reservations that cross the state’s borders into other states. Then there’s Indiana that is partly in one time zone and partly in another.