11–20 of 29 posts
> 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.
https://en.m.wikipedia.org/wiki/Tz_database https://news.ycombinator.com/item?id=10032498
> 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.
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://news.ycombinator.com/item?id=10032498
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".
Does every Docker container, snap, flatpack etc. need to be updated every time the tz database releases a new update? Do they?
Biggest benefit: the timestamps in logfiles are actually correct and make sense.
> 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.
Earlier quoted context omitted.
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://news.ycombinator.com/item?id=10032498
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?
Earlier quoted context omitted.
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://news.ycombinator.com/item?id=10032498
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?
But you should under no circumstances record the offset. Record either a timestamp or local time + location.
Earlier quoted context omitted.
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://news.ycombinator.com/item?id=10032498
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?
But at the last minute, the government announces it's happening on March 4. And your systems haven't yet been updated to reflect this.
So humans move their clocks forward one hour on March 4.
You write somewhere in a text field "March 4 4pm".
"March 4 4pm America/Los_Angeles" doesn't help you, because it's not clear whether you thought "America/Los_Angeles" was -0800 or -0700. And it's not clear whether the system interpreting that date agrees with you.
To be unambiguous, you need to say "March 4 4pm -0700". Otherwise the system might assume the effective timezone is -0800, per the rules it knows. Without unambiguous input, correctly parsing such times is impossible.
You could also use Olson timezones for past events, but then you'd also have to record which version of the timezone rules you were using. And of course nobody does that because it's overcomplicated and unnecessary.
You're right that converting back to 4pm for display is problematic. The simplest solution is to always display UTC. But if you want to convert to the user's preferred timezone, during this time, yes, the system would display 3pm until it got the updated timezone rules. There are more complex solutions, but for most use cases just displaying "March 4 3pm -0800" would be adequate.
Earlier quoted context omitted.
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?
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.