Hacker News Reader

Comment by theoh | Hacker News Reader

This article seems a bit misguided in its dismissal of the significance of historical fact. The last paragraph seems to me to get unnecessarily snotty about somebody making a very precise best-guess reconstruction of a historical value/location. "Out-of-thin-air" values aren't something I had heard of but apparently that category has to do with circular reasoning—so it doesn't apply literally in this case. It's just a self-satisfied way of smearing someone else's good faith work.

View on HN

That's a pretty wild interpretation! I have nothing but respect for the tz db and its contributors; I indicated as much quite explicitly by stating my appreciation for the commentary. Personally I will soon be sending historical corrections to the precise days and times of DST changes in the 1940s for a few places in US and Canada, from my own research.

But yes, it's absolutely a tongue-in-cheek reference to the unrelated notion of "out-of-thin-air" values and reads in memory model semantics. (I've just added a link to an explanation by some PL researchers.)

Nothing but respect? The word "hobbyist" suggests otherwise.

Not really speaking to your point, but: It seems to me that the one minute offset contribution was well intentioned and impressive BUT at the same time quite misguided. I can't see that this addition could possibly ever do anyone any tangible good, but it's obvious how it could cause incredibly destructive, easily missed, hard to track down failure modes for unsuspecting victims, potentially forever.

I don't think the London historical offset should be blamed for such errors, nor should New York's nor any other zone's historical, local mean time offsets. If the tzdb is being used in a buggy way, that's on the user - in this case, pytz. Virtually all systems use tzdb in some form but don't blindly take the earliest historical offsets in a common usage pattern.

Fun fact: for many years the ECMAScript spec states explicitly that JavaScript implementations (i.e., a browser's implementation of JS) should use the wrong time zone information! Wrong in the sense of using an offset for _today_ rather than the offset that was applicable at the time of _the Date object_. Maybe they've changed that in recent years, I can't remember, but here's more info: https://codeofmatt.com/javascript-date-type-is-horribly-brok...

Reply on news.ycombinator.com