# Dates, timezones and DST **URL:** \ **Category:** General Programming\ **Created:** [3 November 2026 11:58 UTC](https://ifnotnil.com/t/dates-timezones-and-dst/4895 "2026-11-03T11:58:09Z")\ **Posts on this page:** 17\ **Page:** 1
**Author:** ![Stretch327](https://ifnotnil.com/user_avatar/ifnotnil.com/stretch327/32/5162_2.png) [@Stretch327](https://ifnotnil.com/u/Stretch327)\ **Post date:** [3 November 2026 11:58 UTC](https://ifnotnil.com/t/dates-timezones-and-dst/4895/1 "2026-11-03T11:58:09Z")
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. ---
**Author:** ![bgrommes](https://ifnotnil.com/user_avatar/ifnotnil.com/bgrommes/32/2651_2.png) [@bgrommes](https://ifnotnil.com/u/bgrommes)\ **Post date:** [3 November 2026 15:17 UTC](https://ifnotnil.com/t/dates-timezones-and-dst/4895/2 "2026-11-03T15:17:21Z")
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. ---
**Author:** ![Stretch327](https://ifnotnil.com/user_avatar/ifnotnil.com/stretch327/32/5162_2.png) [@Stretch327](https://ifnotnil.com/u/Stretch327)\ **Post date:** [3 November 2026 20:12 UTC](https://ifnotnil.com/t/dates-timezones-and-dst/4895/3 "2026-11-03T20:12:56Z")
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. ---
**Author:** ![MarkusWinter](https://ifnotnil.com/user_avatar/ifnotnil.com/markuswinter/32/32_2.png) [@MarkusWinter](https://ifnotnil.com/u/MarkusWinter)\ **Post date:** [3 November 2026 20:44 UTC](https://ifnotnil.com/t/dates-timezones-and-dst/4895/4 "2026-11-03T20:44:31Z")
‘Flat Earthers’? Well, they seem at least to have trouble with the concept of a round Earth … 😉 ---
**Author:** ![TomasJ](https://ifnotnil.com/user_avatar/ifnotnil.com/tomasj/32/4998_2.png) [@TomasJ](https://ifnotnil.com/u/TomasJ)\ **Post date:** [3 November 2026 20:52 UTC](https://ifnotnil.com/t/dates-timezones-and-dst/4895/5 "2026-11-03T20:52:30Z")
well this may not be representaive for everybody, but in aviation everything is measured in UTC. We do not go there to local times 😉 ---
**Author:** ![Stretch327](https://ifnotnil.com/user_avatar/ifnotnil.com/stretch327/32/5162_2.png) [@Stretch327](https://ifnotnil.com/u/Stretch327)\ **Post date:** [3 November 2026 22:21 UTC](https://ifnotnil.com/t/dates-timezones-and-dst/4895/6 "2026-11-03T22:21:30Z")
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. ---
**Author:** ![npalardy](https://ifnotnil.com/user_avatar/ifnotnil.com/npalardy/32/10_2.png) [@npalardy](https://ifnotnil.com/u/npalardy)\ **Post date:** [4 November 2026 00:47 UTC](https://ifnotnil.com/t/dates-timezones-and-dst/4895/7 "2026-11-04T00:47:24Z")
And now Alberta is 2 hours ahead of California where it used to be 1 UGH ! Oh yeah and going north south from Alberta into Montana the time changes as well 😛 ---
**Author:** ![npalardy](https://ifnotnil.com/user_avatar/ifnotnil.com/npalardy/32/10_2.png) [@npalardy](https://ifnotnil.com/u/npalardy)\ **Post date:** [4 November 2026 00:59 UTC](https://ifnotnil.com/t/dates-timezones-and-dst/4895/8 "2026-11-04T00:59:16Z")
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 ```auto 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 ``` ---
**Author:** ![Stretch327](https://ifnotnil.com/user_avatar/ifnotnil.com/stretch327/32/5162_2.png) [@Stretch327](https://ifnotnil.com/u/Stretch327)\ **Post date:** [4 November 2026 11:40 UTC](https://ifnotnil.com/t/dates-timezones-and-dst/4895/9 "2026-11-04T11:40:11Z")
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. ---
**Author:** ![Stretch327](https://ifnotnil.com/user_avatar/ifnotnil.com/stretch327/32/5162_2.png) [@Stretch327](https://ifnotnil.com/u/Stretch327)\ **Post date:** [4 November 2026 12:27 UTC](https://ifnotnil.com/t/dates-timezones-and-dst/4895/10 "2026-11-04T12:27:27Z")
After a discussion with Claude, here’s what we’re going to do… 1. Buoy will bundle new versions of the tzdata each time we build and we’ll make that automatically download the latest file. 2. Buoy will have the ability to download new data itself and compile new versions so devs are not reliant on us for new versions. 3. 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. ---
**Author:** ![npalardy](https://ifnotnil.com/user_avatar/ifnotnil.com/npalardy/32/10_2.png) [@npalardy](https://ifnotnil.com/u/npalardy)\ **Post date:** [4 November 2026 12:51 UTC](https://ifnotnil.com/t/dates-timezones-and-dst/4895/11 "2026-11-04T12:51:31Z")
> [@Stretch327](#): > > 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. 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 They don’t ship IANA files ---
**Author:** ![Stretch327](https://ifnotnil.com/user_avatar/ifnotnil.com/stretch327/32/5162_2.png) [@Stretch327](https://ifnotnil.com/u/Stretch327)\ **Post date:** [4 November 2026 15:28 UTC](https://ifnotnil.com/t/dates-timezones-and-dst/4895/12 "2026-11-04T15:28:26Z")
I was able to find that info for Mac and Linux but not for windows. I’ll have to take another look. ---
**Author:** ![npalardy](https://ifnotnil.com/user_avatar/ifnotnil.com/npalardy/32/10_2.png) [@npalardy](https://ifnotnil.com/u/npalardy)\ **Post date:** [4 November 2026 23:48 UTC](https://ifnotnil.com/t/dates-timezones-and-dst/4895/13 "2026-11-04T23:48:15Z")
I just restarted my Mac and the new TZ files are in place and Xojo works just as I expect since it just maps its DateTime classes to the underlying OS ones No effort to update on Xojo’s part I assume buoy would do much the same on each target for its runtime and just use the OS provided classes & api’s ---
**Author:** ![Stretch327](https://ifnotnil.com/user_avatar/ifnotnil.com/stretch327/32/5162_2.png) [@Stretch327](https://ifnotnil.com/u/Stretch327)\ **Post date:** [5 November 2026 04:14 UTC](https://ifnotnil.com/t/dates-timezones-and-dst/4895/14 "2026-11-05T04:14:18Z")
I did a little more digging about this today and here’s what I found… We _could_ use what’s supplied by each OS but there are some caveats: 1. macOS is the only one that keeps their tables relatively up to date and ship natively with ICU. 2. Linux requires adding another library to the list of system requirements (ICU) 3. The IANA dataset that’s included in Windows 11 is four years old. What Windows appears to do is they keep whatever is current in the OS and then refer to the IANA tables through ICU for older stuff This also explains why Xojo includes three ICU DLLs in Windows builds. ---
**Author:** ![einhugur](https://ifnotnil.com/user_avatar/ifnotnil.com/einhugur/32/5207_2.png) [@einhugur](https://ifnotnil.com/u/einhugur)\ **Post date:** [5 November 2026 11:48 UTC](https://ifnotnil.com/t/dates-timezones-and-dst/4895/15 "2026-11-05T11:48:09Z")
I thought they had stopped including the ICU’s by now ? ---
**Author:** ![Stretch327](https://ifnotnil.com/user_avatar/ifnotnil.com/stretch327/32/5162_2.png) [@Stretch327](https://ifnotnil.com/u/Stretch327)\ **Post date:** [5 November 2026 12:04 UTC](https://ifnotnil.com/t/dates-timezones-and-dst/4895/16 "2026-11-05T12:04:21Z")
It’s possible. I checked what I have, 2024r4.2 ---
**Author:** ![npalardy](https://ifnotnil.com/user_avatar/ifnotnil.com/npalardy/32/10_2.png) [@npalardy](https://ifnotnil.com/u/npalardy)\ **Post date:** [5 November 2026 12:33 UTC](https://ifnotnil.com/t/dates-timezones-and-dst/4895/17 "2026-11-05T12:33:46Z")
ICU on Windows is, or was, if I recall, is for things like text normalization, utf-8 handling, the date formatting options, etc but not for date lookups But NOT the actual tz files themselves Personally I’d avoid trying to include tz files as part of any buoy framework