6 ms·

News for the tz database

121 points by Sir_Cmpwn 8y ago

mikestaszel 8y ago
Amazing work I take for granted. Thank you to all the maintainers and contributors!
simonw 8y ago
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
jessaustin 8y ago
It isn't clear why Ireland would need a negative DST? Don't they also "spring forward and fall back"?
- x1798DE 8y ago
  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)
teddyh 8y ago
Does every Docker container, snap, flatpack etc. need to be updated every time the tz database releases a new update? Do they?
- klodolph 8y ago
  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?)
- mschuster91 8y ago
  On my fleet I simply bind-mount /etc/timezone and /etc/localtime from the host (the latter sourced from /usr/share/zoneinfo/Europe/Berlin). Biggest benefit: the timestamps in logfiles are actually correct and make sense.
- isostatic 8y ago
  Isn't the idea behind containers that they only persist for a few days in any case, before being rebuilt?
jwilk 8y ago
You linked to a copy embedded in pytz. Upstream database is here: https://github.com/eggert/tz https://github.com/eggert/tz
- sctb 8y ago
  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.
mikelward 8y ago
> 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 8y ago
  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 8y ago
    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?
    - MattHeard 8y ago
      A timestamp should not be used to record location.
    - treve 8y ago
      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 8y ago
        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.
uiri 8y ago
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).
kstrauser 8y ago
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".
jjuhl 8y ago
Time (handling) sucks.
- squirrelicus 8y ago
  You should try non terrestrial software dev where time dilation has to be accounted for.
btilly 8y ago
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 8y ago
  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
lifeisstillgood 8y ago
>>> zic no longer outputs a dummy transition at time -259 (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 :-)
kccqzy 8y ago
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-zone-database https://www.eff.org/press/releases/eff-wins-protection-time-...
- breakingcups 8y ago
  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."
gee_totes 8y ago
> Use "PST" and "PDT" for Philippine time. What about us in Pacific daylight time? Now our timezone acronym is ambiguous.

121 points by Sir_Cmpwn 8y ago

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

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

jessaustin 8y ago

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

x1798DE 8y ago
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)

teddyh 8y ago

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

klodolph 8y ago
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?)
mschuster91 8y ago
On my fleet I simply bind-mount /etc/timezone and /etc/localtime from the host (the latter sourced from /usr/share/zoneinfo/Europe/Berlin). Biggest benefit: the timestamps in logfiles are actually correct and make sense.
isostatic 8y ago
Isn't the idea behind containers that they only persist for a few days in any case, before being rebuilt?

jwilk 8y ago

You linked to a copy embedded in pytz. Upstream database is here: https://github.com/eggert/tz https://github.com/eggert/tz

sctb 8y ago
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.

mikelward 8y ago

> 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 8y ago
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 8y ago
  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?
  - MattHeard 8y ago
    A timestamp should not be used to record location.
  - treve 8y ago
    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 8y ago
      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.

uiri 8y ago

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

kstrauser 8y ago

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

jjuhl 8y ago

Time (handling) sucks.

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

btilly 8y ago

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 8y ago
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

lifeisstillgood 8y ago

>>> zic no longer outputs a dummy transition at time -259 (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 :-)

kccqzy 8y ago

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-zone-database https://www.eff.org/press/releases/eff-wins-protection-time-...

breakingcups 8y ago
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."

gee_totes 8y ago

> Use "PST" and "PDT" for Philippine time. What about us in Pacific daylight time? Now our timezone acronym is ambiguous.