It’s straightforward, if perhaps a bit complex, to write a clock app that knows when DST is in effect for your current location. How do apps handle it when the government changes those dates?
I assume they release an updated version of the app? Even better, they just get the current time from the phone itself.
The developers patch the software to account for the change in DST rules.
There’s a timezone database.
I’m not sure who maintains it, because it’s extremely complicated.
https://www.iana.org/time-zones
For Unix and Linux systems, a series of text (human-readable) but also computer-readable timezone definition files are installed at system setup. These are used by the operating system’s timekeeping software to make time zone adjustments to the local time computed from the monotonically advancing epoch time (a running count of rhe number of seconds that have elapsed aince midnight January 1st 1970).
These timezone files are maintained by the operating system provider and routinely patched on user systems along with everything else that gets updated periodically, so timezone rules almost always get updates before they’re needed.
Modern Unix based systems use the TZ database. It does need constant updating, as it covers all countries, timezones, and interestingly includes historical information of time shifts. So whenever a country decides to change either the date of time change or even how much, it is captured.
This has a very interesting effect. Internally time is kept in UTC. It is only when time is displayed for a user that the time is converted to whatever the time zone is set to. The time zone is simply set by the TZ environment variable. (There is a system default.) Since the TZ system knows about historical timezones, you can see the time (of say a file creation) that might be a decade ago, still correctly shown taking into account the DST setting in force at that date. Indeed the database goes back into historical times for when there are records. It is fascinating to see the UK use double daylight saving during WW2. The TZ system is independent of the Unix time epoch. You just feed it a time and date relative to UTC, and it will give you back the shifted time.
Before this came into use, Unix was utterly dumb. If you were lucky the system used UTC and there was a system wide offset to get your time zone. Early Unices only allowed the offset for UTC to be positive. Which was fine for the USA, but broken on the rest of the planet. Allowing negative offsets was one battle, allowing non integer offsets yet another.
Smartphones can get the timezone when they connect to local towers. I’ve noticed that when I fly across timezones, the clock shows the origin time until a few minutes after I arrive.
Is there a way for an app to query the database without downloading the entire thing to find out the current DST dates for a given location?
It’s one guy, Paul Eggert. Not a joke, it’s one guy, and a small team of volunteers maintain a database of time zones and time changes. The database is now under the auspices of the Internet Assigned Numbers Authority (IANA), but it’s still run by Eggert.
Like all good jokes, the following XKCD comic is based in far too much truth. Eggert is from Kansas, though.
Helpfully, if all you want to do is find out what time it will be in a particular place on a certain day, the https://www.timeanddate.com/ website is an excellent tool.
All true. With emphasis on that “almost” at the end.
Just recently some populist know-nothing government someplace decided on a couple day’s notice that they would not being doing DST this year as they always had. “The people have spoken” or some such BS.
Considerable chaos ensued. I’m not sure how it resolved.
I forget. Where was this?
I’d like my app to know in advance when DST starts and ends without having to constantly be checking against some time reference. It’s already got the current U.S. system hardcoded (I don’t expect any international users) and it does the gyrations to figure out what Xth Sunday in Pentember means, but I’m trying to future-proof it. I’m running the app on a limited system that can’t handle fetching, uncompressing, and parsing an entire database, but it can do the occasional small http query to see if the rules have changed.
There are various APIs. Googling got me just a few:
Here’s an example of a simple query-and-response HTTPS API provided by Google.
Quoting that article:
Request the time zone information for a specific latitude/longitude pair and date. The API returns the name of that time zone, the time offset from UTC, and the daylight savings offset.
So such lookup services do exist.
(As @AlsoNamedBort mentioned.)
Yes, I found those things when I tried to google my question first, and as far as I can tell, these things all tell me what the current DST offset is, but they don’t return the date of when the next DST change will be, do they? Or the rules for calculating those dates?
There are standard formats for determining time zone changes.
https://developer.ibm.com/articles/au-aix-posix/
The tzinfo files contain rules from which the next time change can be computed, like “change on the last sunday of march for years between these years” but DST rules are routinely updated by national governments so and “computation” is not guaranteed to work in the future.
I don’t think it is sophisticated enough to have rules like “time changes during ramadan” listed as anything other than just a series of dates.
I’ve been out of the cell phone game for a decade, but back when I was involved, even that part was surprisingly tricky. Towers reach across time zones. Time zone lines aren’t straight.
I don’t remember all the other complications, but a friend of mine at work was responsible for a good bit of testing in this space, and used to talk about all the ways things could go wrong.
They don’t, sometimes. In 1999, Microsoft got the transition dates for Brazil wrong. I know because I was responsible for an email gateway I’d written for a large U.S. automobile manufacturer, and spent a bunch of time trying to figure out how I got it wrong. I hadn’t.
It seems to be extremely small (~500k zipped), so I’m not sure that anyone going to all the trouble to set up some sort of service to field requests is going to really save anyone anything vs. just downloading the entire thing every now and then (you really only need it a maximum of twice a year).