Xojo.Core.TimeZone Questions

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.

And yes, I’m hitting the new Date class with some degree of thoroughness. :slight_smile:

The Problem With Time and Timezones

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:

http://en.wikipedia.org/wiki/List_of_UTC_time_offsets

http://en.wikipedia.org/wiki/List_of_time_zone_abbreviations

[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:

http://en.wikipedia.org/wiki/List_of_UTC_time_offsets[/quote]

Would be nice to place this link next to the xojo.core.date constructor in the LR. I had tried “UTC+1” and “UTC-1” and got an error, before I realized it was “UTC+01:00”.

The TimeZone constructor does not accept other abbreviations than UTC and GMT, apparently. Besides, the list shows UTC+1 and the like as well which is not valid either.

First link was just a visual representation showing how not all timezones are on the hour. :slight_smile: Look at the second link for TZ abbreviations.

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.

Yee haw !

Forming the timezone with “UTC+01:00” works, but not abbreviations. That was what I was trying to say. Anyway, it is somewhat simpler to indicate the delta, rather than to seek the abbreviation.

That’s an awesome video, Joe. Thanks for sharing.

Dragons …

Tried this from http://xojo.helpdocsonline.com/date$TZ

Dim t As Text = d.ToText(Locale.Current, Date.FormatStyles.Short, Date.FormatStyles.None)

Locale shows “this item does not exist”…

It would certainly appear so.

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.

Use Xojo.Core.Locale.Current.

Yes, that was it.

I would think it better to store everything in GMT, so the database engine can do comparisons. Convert to local time for display only.

Dunno. This is literally the code in my desktop project:

lblResult.text = d.ToText(Xojo.Core.Locale.Current, auDate, auTime)

auDate and AuTime are Auto’s that are set like this: auDate = Xojo.Core.Date.FormatStyles.Short

That’s what I’m doing now with the old Date class but I just want to make sure there’s nothing better with the new Framework date class.

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.

Great video!

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.

I think I’ll go have another beer.