"(Sorry about that, but we can’t show files that are this big right now.)"

1.3MB and it's actually raw code. Amazing.

Daylight Savings Time should die in the fires of hell.

I couldn't agree more - to boot, DST going away solves like half of the edge cases with one quick fix.

Except that removing DST won't, if you ever need to calculate a time/date for any time before its (future, hypothetical) removable. That could actually create more bugs.

Probably won't, historical DST switches (and TZ offsets) are already one of the edge cases a TZ library needs to deal with (I'm looking at you, Argentina!).

We didn't have DST in most of Indiana until about 10 years ago. When we switched, most of us were wondering why the hell we were even doing it. It's really not necessary, it confuses people, leads to screwed up schedules when the switch happens, and the fact that there are still a few counties that don't observe it screws things up even more.

Operating systems kind of suck at it. Which is why for Elixir I made Tzdata (https://github.com/lau/tzdata) not rely on any timezone information from the operating systems. A feature I would like from operating systems is to tell me the true time during leap seconds. E.g. 23:59:59, 23:59:60, 00:00:00 Instead of repeating 23:59:59 or just pretending the leap second never happens.

> A feature I would like from operating systems is to tell me the true time during leap seconds. E.g. 23:59:59, 23:59:60, 00:00:00 Instead of repeating 23:59:59 or just pretending the leap second never happens.

In past discussions of leap seconds, it came out that the POSIX standard specifies that no such second as 23:59:60 can exist (by specifying that "one day" consists of exactly 86400 seconds). As I understand things, this is why the erroneous behavior you mention is done.

It is not clear to me why, for the sake of complying with a standard we know to be wrong, we report false information and otherwise do things that we also know are wrong. The obvious approach would seem to be to either change the standard or just ignore it.

I just checked if you can get around it by using unix time, but holy shit, it is poorly designed. Unix' seconds since epoch is not the actual absolute number of seconds since 00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970, it doesn't count leap seconds. I wonder if you can even get a reliable TAI from linux, so you can abandon all this shit and implement proper time handling yourself.

Edit: Seems like we can specify CLOCK_TAI for clk_id on linux now.

> Operating systems kind of suck at it.

Sure, but they usually have more resources than programming language teams. Consider all the programming languages on your machine. Can you trust they all did the timezone, with all its nuances, correctly?

Consider something simpler - the trig functions. I've noticed time after time that many language libraries get it wrong, and this is with decades of development. Errors are usually in the form of precision that is lower than it should be, and poor handling of special values like NaN and infinity.

The situation with that is so erratic that with the D programming language we'd write our own trig implementations rather than use the C library ones.

They might have more resources, but they also have constraints. For instance a tzdata update was just released yesterday. Apple has a lot of resources but I don't see an updated from them today on iOS nor Mac OS X. Elixir tzdata automatically updates to the new version.

Does Apple even have resources that work on tzdata code? Or do they just use open source code?

I wrote more about the issue here: http://www.creativedeletion.com/2015/12/03/timezone-updates-...

In particular for Elixir I trust the time zone data from Tzdata more than for any other language, mostly because I know it is designed to have up to date data. (And well, I know the code because I wrote it myself.)

Even if a system is good in many ways it does not matter if the data is not up to date.