
News for the tz database - Sir_Cmpwn
https://github.com/eggert/tz/blob/master/NEWS
======
simonw
One of my favorite surprising corners of the internet is the tz mailing list,
where updates to the tz database are actively discussed:

[https://mm.icann.org/pipermail/tz/2018-July/thread.html](https://mm.icann.org/pipermail/tz/2018-July/thread.html)

The amount of effort and detail that goes into this database is astonishing -
every few days there's a new twist introduced by timezone legislation
somewhere around the world.

Even more impressive is their dedication to building a correct database of
historic timezone changes - here's a post where someone submitted further
details on the history of time in Macau for example:
[https://mm.icann.org/pipermail/tz/2018-May/026467.html](https://mm.icann.org/pipermail/tz/2018-May/026467.html)

------
kstrauser
This is like catnip to me. There's a tiny little critical corner of the
Internet where dedicated volunteers bust their tails to make sure they get the
details excruciatingly correct.

It's also a useful reminder to never, ever attempt to do datetime math on your
own. _Always_ use a library! And if that library is buggy, submit patches but
_don 't_ say "aww, I'll just do it myself".

------
kccqzy
And while we cherish the work of volunteers maintaining this database, let's
not forget that this database was once the subject of a meritless lawsuit:
[https://www.eff.org/press/releases/eff-wins-protection-
time-...](https://www.eff.org/press/releases/eff-wins-protection-time-zone-
database)

~~~
breakingcups
The statement from the accuser was refreshing though:

In a statement, Astrolabe said, "Astrolabe's lawsuit against Mr. Olson and Mr.
Eggert was based on a flawed understanding of the law. We now recognize that
historical facts are no one's property and, accordingly, are withdrawing our
Complaint. We deeply regret the disruption that our lawsuit caused for the
volunteers who maintain the TZ database, and for Internet users."

------
uiri
They're removing East Saskatchewan? That was my favourite nonsense time zone.
They're right that it should have been "West Saskatchewan", but I suppose
Saskatchewan on its own is enough for the province outside Lloydminster, and
Lloydminster uses Alberta (Mountain) time anyways which makes a second
Saskatchewan timezones redundant (for now).

------
mikestaszel
Amazing work I take for granted. Thank you to all the maintainers and
contributors!

------
lifeisstillgood
>>> zic no longer outputs a dummy transition at time -2 __59 (before the Big
Bang), as clients should no longer need this to handle historical timestamps
correctly.

Ok, when we consider events prior to the Big _freaking_ Bang as historical,
_and_ have test code for it, then I feel we are in safe hands.

Keep up the good work folks :-)

------
teddyh
Does every Docker container, snap, flatpack etc. need to be updated every time
the tz database releases a new update? Do they?

~~~
klodolph
It is not necessary. Various backend systems can store dates and times as UTC,
or UTC + time zone offset, and these cover the most common use cases. You can
use these formats to communicate with clients, and have clients do the
conversion for you, for example, in a browser you can use
Date.getTimezoneOffset. One good thing about this is that if the time zone
data is incorrect on a client's device, there is a reasonable chance that the
client's clock is also showing the wrong time anyway. Most client OSs are
aggressively updated so this is mostly solved. The remaining problems are any
systems that need to do calendrical math, for example, calendar programs.

In practice, however, people write bad date/time code often enough that it’s a
problem. I was recently using a client library that was completely broken if
the client’s system had a negative offset from UTC more than 1 hour.

At work we get emails if we leave any container running that was built too
long ago (three months or something?)

------
btilly
Reading through this just underscores how ridiculous it is that UTC itself has
leap seconds. The mapping between the clock and our labeling of the clock
varies so often, who cares about whether the underlying clock matches the Sun
to the nearest second at a physical location that few of us will ever visit?

~~~
JdeBP
Can we interest you in International Atomic Time? It is, after all, the Atomic
Age. And the tz database does have "right" timezones.

* [http://cr.yp.to/libtai/tai64.html](http://cr.yp.to/libtai/tai64.html)

------
jessaustin
It isn't clear why Ireland would need a negative DST? Don't they also "spring
forward and fall back"?

~~~
x1798DE
In the Summer they call their time "Irish Standard Time", which indicates that
they view the summer offset as the standard one and they are using "winter
time" [1]. It's just a matter of perspective.

[1]
[https://en.wikipedia.org/wiki/Winter_time_(clock_lag)](https://en.wikipedia.org/wiki/Winter_time_\(clock_lag\))

------
mikelward
> Use "PST" and "PDT" for Philippine time.

I wonder if this will break anything. Some systems make the bad assumption
that timezone abbreviations are unique, e.g. when parsing dates.

~~~
mikelward
And the "changes to past timestamps" is why you can't even store past events
using Olson timezone names like America/Los_Angeles: you have to use UTC
and/or timezone offsets like -0700.

[https://en.m.wikipedia.org/wiki/Tz_database](https://en.m.wikipedia.org/wiki/Tz_database)
[https://news.ycombinator.com/item?id=10032498](https://news.ycombinator.com/item?id=10032498)

~~~
0x0
Is it not the opposite, though? If you need to store the fact that an
important meeting took place in Los Angeles at exactly 4.00pm on a specific
date, if you had used utc/offsets, it would look like the meeting took place
at 3.59.50pm or whatever change was done to correct the tz data for historical
timezones?

~~~
treve
It really depends on the use-case. If you had a meeting at a specific wall-
time you'll want the timestamp to change. If you recorded a timestamp for when
something happened, the local time should change.

But you should under no circumstances record the offset. Record either a
timestamp or local time + location.

~~~
mikelward
I agree that systems should record times in UTC. But I'm talking about a more
nuanced edge case: parsing user-entered date strings. If a user says "4pm Los
Angeles", it could be ambiguous, and recording the offset is the only way to
reliably disambiguate. See my reply above.

------
gee_totes
> Use "PST" and "PDT" for Philippine time.

What about us in Pacific daylight time? Now our timezone acronym is ambiguous.

------
jjuhl
Time (handling) sucks.

~~~
squirrelicus
You should try non terrestrial software dev where time dilation has to be
accounted for.

------
jwilk
You linked to a copy embedded in pytz.

Upstream database is here:

[https://github.com/eggert/tz](https://github.com/eggert/tz)

~~~
sctb
Thanks, we've updated the link from
[https://github.com/stub42/pytz/blob/master/tz/NEWS](https://github.com/stub42/pytz/blob/master/tz/NEWS).

