7 ms·
Social issues aside, the software perspective of keeping up with DST is very costly. Every time any government entity anywhere on Earth changes its mind about
by imglorp 6y ago
Social issues aside, the software perspective of keeping up with DST is very costly.
Every time any government entity anywhere on Earth changes its mind about what zone they're in and when, the IANA needs to reissue the TZDB. Then every OS and platform vendor needs to patch up to a new TZDB. Just for laughs, Java seems to have its own TZDB so in general your OS and application layer might disagree about zones.
This is all okay for most users who just get an automated OS push, but some vendors operating national networks that need to do some things in localtime need to upgrade their platforms and do acceptance testing every time.
And then there's bugs.
Just for example about the variations, here's a recent TZDB change, seems Fiji is rejiggering their dates only a month away. See the archives for many more.
https://mm.icann.org/pipermail/tz-announce/2020-October/000060.html https://mm.icann.org/pipermail/tz-announce/2020-October/0000...
https://www.iana.org/time-zones https://www.iana.org/time-zones
- Jabbles 6y agoThat won't go away, software will still be needed for when states inevitably change their timezones.
- ryandrake 6y agoRight. OP's is more an argument against time zones than Daylight Saving Time. Honestly though, this should only be a problem for the small subset of embedded software without access to the Internet. If major OSes time zone databases are not able to be updated independently of the rest of the OS, that's kind of on them. We know time zone boundaries have been changing arbitrarily for decades, so shouldn't this be a solved problem?
- imglorp 6y agoNot against zones; I was hoping to shine a light on all the complexity around the TZDB, which is a mapping of zones to switchover times. Eg, $ zdump -v US/Eastern | grep 2020 US/Eastern Sun Mar 8 06:59:59 2020 UT = Sun Mar 8 01:59:59 2020 EST isdst=0 gmtoff=-18000 US/Eastern Sun Mar 8 07:00:00 2020 UT = Sun Mar 8 03:00:00 2020 EDT isdst=1 gmtoff=-14400 US/Eastern Sun Nov 1 05:59:59 2020 UT = Sun Nov 1 01:59:59 2020 EDT isdst=1 gmtoff=-14400 US/Eastern Sun Nov 1 06:00:00 2020 UT = Sun Nov 1 01:00:00 2020 EST isdst=0 gmtoff=-18000 If everyone simply picked a zone and stayed there, without the switching schedule above, you'd only need a mapping of zone to GMT offset and be done with it.
- ryandrake 6y agoAhh you’re right. Missed that!
- Dylan16807 6y agoI expect that to happen far less often.
- app4soft 6y ago> the software perspective of keeping up with DST is very costly. To be clear, the software perspective is to use Unix time instead.[0] [0] https://en.wikipedia.org/wiki/Unix_time https://en.wikipedia.org/wiki/Unix_time
- imglorp 6y agoNot really. Most machines use UTC internally (with varying epoch dates to represent it). And this is absolutely great until you need to interface with meatbags, ie local time. It's not just display of time either: think about anything Cron does in localtime, eg backups or open building door locks, or send an ACH payment file; then ponder all the corner cases of DST switches. Eg do you do something twice, or never? What if you reboot somewhere in the DST switch period? etc. All these shenanigans are dictated by the TZDB. Oh, and UTC also contains leap seconds.
- hunter2_ 6y agoI doubt anyone wants something to occur twice, but they might have an opinion on whether a 1:30am job should occur on the first 1:30am or the second 1:30am in the fall change. For the spring change, I think all jobs scheduled between 2am and 3am (a period that collapses into a moment) should ideally occur at said moment, but I can see how a smear might be more practical in many cases. I don't recall how `cron` and other schedulers handle it, though.
- zwily 6y agoEvery software service I’ve worked on has had issues around DST transitions. That’s really the only programming benefit I see for getting rid of it going forward.
- disgruntledphd2 6y agoI worked at a big tech company for half a decade, and without fail, every year there was some kind of serious bug caused by DST. Things either happened twice or never, it was always really painful. In any growth company, I would imagine that these things keep occurring, as people haven't hit the bugs themselves yet.
- ehvatum 6y agoThe George W Bush time change was the epitome of this, for me. Oh yeah, I’m updating TZ files because W CARES ABOUT GLOBAL WARMING!!!
- jcranmer 6y ago> seems Fiji is rejiggering their dates only a month away If I recall, Egypt's DST change several years ago was announced so close to the changeover that IANA was updated after it happened. It's possible there is even an instance where the DST change was enacted retroactively.
- SahAssar 6y agoThe West Bank has (had?) timezones that are based on ethnicity, not geographic location: https://www.972mag.com/the-worlds-only-ethnic-time-zone/ https://www.972mag.com/the-worlds-only-ethnic-time-zone/
- mjlee 6y agoEvery time I consider this I'm reminded of an incident where 3 Israeli Arabs blew themselves up instead of their target, probably due to daylight savings time. https://www.independent.co.uk/news/world/clocks-change-killed-bombers-1117380.html https://www.independent.co.uk/news/world/clocks-change-kille...
- taliesinb 6y agoThat’s straight out of Tintin and the Broken Ear, where a would-be terrorist blows himself up after a time change: https://imgur.com/gallery/27jxctY https://imgur.com/gallery/27jxctY
- sdenton4 6y agoI have a collection of 'mistakes you make exactly once,' mistakes that are so obvious in retrospect and terrible in consequence that you would never, ever do it again. This is a whole other class, though.
- hyiltiz 6y agoCare to share? I am sure that would be very useful for me (and probably many others).
- tgv 6y agoVery costly? That would require some serious evidence. And even then, so what?
- brandmeyer 6y ago> And even then, so what? I have to agree. The function of software is to reflect the state of reality as it is. Human sociopolitical reality is complicated; that's just a problem to deal with.
- jt2190 6y ago> Java seems to have its own TZDB so in general your OS and application layer might disagree about zones. More precisely, the Java Virtual Machine (not the programming language) will, like any operating system running inside a VM, need to be patched with the new time information. Updating the host machine’s time info is not enough.
- heavenlyblue 6y agoWhy does JVM need to know about time zones?
- lou1306 6y agoI guess it allows you to implement a JVM that runs on bare metal, or a host without timezone support.
- jholloway7 6y agoYep, it makes it easier to port the JRE to platforms like Windows that have an entirely different TZ system. Python, for example, has the same problem. Historically, Python took the stance of providing a "naive" datetime module that provides a conversion API, but delegated the actual TZ conversion to external implementations (dateutil, pytz). Only recently (as of 3.9) have they added a stdlib implementation that uses system-level zoneinfo by default.
- adrianmonk 6y agoIt's not the VM engine (JIT compiler, etc.) itself, of course. It's a data file that resides in the Java Runtime Environment directory, and some of the standard library code uses this file. I assume it's done this way because it's the most foolproof way to get consistency across all platforms. If Java did delegate, it might be hard (or even impossible?) to get the same behavior out of all the different underlying APIs on each platform. And it would be challenging to create the tests to validate that it really does behave consistently. Also, although it creates extra maintenance work, it has the advantage that it decouples Java-level and OS-level updates. Suppose development machines run one OS (with its TZ data) but QA and production run a different OS. To harmonize environments as closely as possible, it's helpful that you can keep the TZ data versions on all JVMs in sync without relying on multiple OS vendors' patch processes to enable that.
- mschuster91 6y ago> Just for laughs, Java seems to have its own TZDB so in general your OS and application layer might disagree about zones. Java also ships their own SSL trust store instead of using the system one. Why, just why?! Every system capable of running Java also has its own trust store...
- diroussel 6y agoYeah, I find this really annoying too. Java has all the right integration to windows trust store and you can write custom code to use it. But it’s not sued be default. This makes using internal CAs a nightmare.
- toast0 6y agoEven if that is true now, it certainly wasn't always true. When did Java add its trust store, and when did Windows and Debian and Solaris? There's also a consistency issue --- write once, run everywhere doesn't work if you need to resign your webstart program based on the OS you're running on.
- lodovic 6y agoNot sure about that, the Windows certificate store has been around since forever, perhaps even since Windows NT. The same goes for certificate management in Linux. I think it was mostly because it was far easier for the Java team to roll their own extendable store instead of doing all the platform integration themselves.
- SahAssar 6y ago> Every system capable of running Java also has its own trust store No, they don't: https://en.wikipedia.org/wiki/Java_Card https://en.wikipedia.org/wiki/Java_Card there are also other examples of java running in embedded and semi-embedded scenarios where a TZDB and a SSL trust store would not be guaranteed by the host.
- grishka 6y agoThis reliance on OS updates is a really big problem for devices that rarely receive any, like Android phones. As an Android developer in Russia who worked on a very popular app when our government changed timezones, and then did it once again a year later, I wasn't thrilled. People started doing the silliest thing: instead of picking a timezone with the correct offset, they just set the time to read correctly, thus shifting the unixtime by an hour. They then proceeded to complain that my app doesn't show relative dates correctly (I just posted it but it says hour ago). Had to add an ugly workaround involving getting the known-correct current unixtime from the server and using the offset from that in all my time calculations. Fun times. And no, you can't update the timezone database yourself. It resides on the system partition which requires root or at least an unlocked bootloader to mount as writable.
- reader_1000 6y ago> Just for laughs, Java seems to have its own TZDB Well, there is also Joda time and icu4j that have their own TZDB which caused me one very stressful day until we found this fact.
- apaprocki 6y agoTo the original point, then there’s people like me that spend time actively ripping out “vendored” copies of tzdb in OSS libs to make them instead use “the one true copy” that is itself painstakingly kept accurate everywhere. Then add the extra time required to update those patches when new versions are released... Copying/vendoring dependencies like that is a great shortcut for a project but creates a huge hassle in large systems (a single OS counts, thousands of packages).