While working on named timezones for Buoy, a thought came to me that made me wonder how others deal with it.
The problem
If you use named timezones, let’s say America/Atlanta, daylight savings time start and end dates have changed over the years and cause UTC offsets to be different, especially for displaying historical dates. IANA publishes updates quarterly.
The question
So what do people currently do? Do you guys monitor IANA and update your apps periodically? Just update quarterly to avoid this issue? Or is this an “oh shit” moment for you?
P.S: macOS handles this for you within their support windows, Windows recently added these tables and Linux only installs them on certain distros.
Personally my use of time zones is pretty limited and forgiving. I am receiving data from companies in the continental US and Canada. The server that processes these files is on UTC / GMT. I have a couple of edge cases where I need to know what time it is in the data contributor’s time zone. In another case I have maintenance routines that rebuild DB indexes and they need to run in the correct but slower “don’t lock everything” mode during business hours, which I define as “between 8am Eastern and 5 pm Pacific”, the window of time when most users are hitting the system.
To determine these things I just take the system time and convert it to the desired time zone. If it’s off by an hour, it’s not the end of the world. So for example Arizona and British Columbia can be an hour off and it’s okay.
I’m thinking about this a lot recently because of a situation at work where some of the employees just can’t wrap their heads around time zones and often complain that when I get to work that the task they assigned to me at 9am isn’t done yet… 9am Israel time that is… 7 hours ahead of us, or 2am my time.
I just remember my time at the mail forwarding company when people who traveled all over the world didn’t understand that we couldn’t get their mail to them today just because it was already tomorrow where they were on the other side of the international date line… as if we snapped our fingers and their mail just appeared on their boat.
I thought TZ files made it possible to get the right offset on the right date because they tracked all the vagaries & changes
So if I created a new date object representing local date & time 2024-11-28 12:00:00 it would have the correct TZ off set (-7 at that point in time)
If I created one for a date in August 2026 it would have been -6 (daylight time)
But if I create one or today it should be -6 since we started staying on DST permanently Nov 1
This code gets the right TZ offset & timezones in Xojo so .. there’s that
Dim date1 As New DateTime( 2024, 11 ,28 ,12 , 0)
Dim date2 As New DateTime( 2026, 08 , 8 ,12 , 0)
dim date3 as DateTime = datetime.Now
break
What I’m weighing is how to deal with that long term. Since these tables are published by the IANA quarterly, that also puts the burden on Buoy to update the table and release quarterly. (It also puts another dent in xojo’s forever license). If you want Alberta to be correct going forward, you’re going to need to upgrade your Xojo or write your own workaround.
These data files, once compiled and compressed still add up to a few hundred K. I’m looking into whether Buoy can include just the parts that are actually used, whether through constants to string literals, and whether the whole engine needs to exist if there are no named timezones at all. The flip side is that if you used a variable to create a timezone, you’d end up getting the whole kit-and-kaboodle.
One thing I’m sure of is that I’d like to make them downloadable by the Buoy compiler itself, so devs can update them whenever they want, assuming that’s even possible. Even better would be to allow apps themselves to do it so if you didn’t want to need to re-ship your app, you could do that.
Here’s an excerpt from the Claude unit test run that you might find interesting:
The engine agrees with Python’s zoneinfo on every one of the 597 zone names, over 131,340 instants (offset, DST flag and abbreviation), and on 620,484 wall-clock times including every real transition from 1950 to 2040.
After a discussion with Claude, here’s what we’re going to do…
Buoy will bundle new versions of the tzdata each time we build and we’ll make that automatically download the latest file.
Buoy will have the ability to download new data itself and compile new versions so devs are not reliant on us for new versions.
The Timezone class will have a mechanism for loading new files so if you wanted to, you could host new tzdata files with a hash and a signature and update the data on the fly yourself.
Why ?
Xojo uses the systems underlying date time classes to implement theirs & this will update & act accordingly as timezone files are update by OS updates
