The West Bank has (had?) timezones that are based on ethnicity, not geographic location: https://www.972mag.com/the-worlds-only-ethnic-time-zone/

Every 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-kille...

That’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

I 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.

Care to share? I am sure that would be very useful for me (and probably many others).

This 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.

> 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.

> 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...

Yeah, 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.

> Every system capable of running Java also has its own trust store

No, they don't: 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.

Even 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.

Not 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.

> 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.

To 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).

That won't go away, software will still be needed for when states inevitably change their timezones.

I expect that to happen far less often.

Right. 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?

Not 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.

Ahh you’re right. Missed that!

> 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.

Why does JVM need to know about time zones?

It'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.

I guess it allows you to implement a JVM that runs on bare metal, or a host without timezone support.

Yep, 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.

Java is not an operating system. Other environments, such as .NET Core, don’t have any issues using the OS timezone database: https://devblogs.microsoft.com/dotnet/cross-platform-time-zo...

> 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

Not 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.

I 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.

Every 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.

I 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.

> Most machines use UTC internally

No, they rally aren't. Most machines use Posix time internally, and the fact that it doesn't reflect real-world leap seconds is a problem.

Unix time says nothing about which timezone you're in.

I think that's the point

Very costly? That would require some serious evidence. And even then, so what?

> 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.

Software developer: The world should adjust in order to make my life as easy as possible.

The world: LOL

Agree, but it's our job as nerds to tell society about this cost.

Society's job is to weigh this cost with all the others +/- and decide what to do.

The 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!!!