Timezone Bullshit
blog.wesleyac.com
Timezone Bullshit
1–10 of 334 posts
Re: Timezone Bullshit
#2> Let's take take a look, using the disastrously bad unix libc timezone tools
Are there any more examples of them causing issues to warrant being called "disastrously bad"? This post just seems to have one example of bad error handling when they the TZ env var is set incorrectly.
I'm genuinely interested if they actually are bad since they are used a lot.
Re: Timezone Bullshit
#3> Let's take take a look, using the disastrously bad unix libc timezone tools
It seems to me that the author did not initially read the documentation they linked to (https://www.gnu.org/software/libc/manual/html_node/TZ-Variab...) and is now complaining in an annoying and entitled manner.
Re: Timezone Bullshit
#4> Let's take take a look, using the disastrously bad unix libc timezone tools Are there any more examples of them causing issues to warrant being called "disastrously bad"? This post just seems to have one example of bad error handling when they the TZ env var is set incorrectly. I'm genuinely interested if they actually are bad since they are used a lot.
They usually work because people check and notice mistakes.
It gets worse now that you have countries next to each other that are out of sync on daylight saving - America/Los Angeles doesn’t work for those south of the border anymore - but you won’t notice except two weeks a year.
Strangely I’ve noticed some systems give you WAY more cities than in the standard library - and I’m not sure why. Linode had way more options than just America/Chicago but didn’t have St Paul.
And trying to schedule things in advance across the daylight saving time difference is even more confusing.
Re: Timezone Bullshit
#5The only situation where our datetime instances deal with timezones is on a one way trip to a user's display, document or email. If you are playing around with parsing timezone strings, you are probably making a huge mistake unless you are parsing someone else's trash data.
I feel the standard interchange format for datetimes really should be 64 bit Unix timestamps. These are trivial to store in any database as a native type, can be compared using the fastest arithmetic instructions possible, and are a locale agnostic representation suitable for direct business logic comparisons.
Trying to carry timezone information around is a mistake. This is state that should be terminated and normalized at both ends, not passed through the system.
The only thing I would store pertaining to timezone is for user profile or server environment configuration. These would be settings in the application that are used to produce locale-specific UI and reports.
There are probably some other use cases I am not thinking of, but that is the extent of how we do it and we have a really complex app that has to serve customers who operate in multiple timezones at once.
Re: Timezone Bullshit
#6The only situation where our datetime instances deal with timezones is on a one way trip to a user's display, document or email. If you are playing around with parsing timezone strings, you are probably making a huge mistake unless you are parsing someone else's trash data. I feel the standard interchange format for datetimes really should be 64 bit Unix timestamps. These are trivial to store in any database as a nat…
Hmm, your applications don't have user input asking for a time?
Re: Timezone Bullshit
#7> Let's take take a look, using the disastrously bad unix libc timezone tools It seems to me that the author did not initially read the documentation they linked to ( https://www.gnu.org/software/libc/manual/html_node/TZ-Variab... ) and is now complaining in an annoying and entitled manner.
Not defending/attacking the phrase "disastrously bad", but I'm not sure its a fair argument to say "the docs explain it", if the behavior isn't what a "reasonable" person would expect. Writing software that deletes your files (when you expect, say, the weather report) isn't excused if they write in the docs "oh this weather software randomly deletes files for no reason".
In this specific case though, even those docs do not explain what happens if the value is "invalid"!
Re: Timezone Bullshit
#8> Let's take take a look, using the disastrously bad unix libc timezone tools It seems to me that the author did not initially read the documentation they linked to ( https://www.gnu.org/software/libc/manual/html_node/TZ-Variab... ) and is now complaining in an annoying and entitled manner.
It's absolutely right to criticize insane behavior even if said behavior is documented. LOL "helpfully" being substituted to the output is absolutely insane.
Re: Timezone Bullshit
#9> There are actually two timezones that are canonically named "CST", and they're 14 hours apart!
Yup. If you say CST do you mean China Standard Time or Central Standard Time? The answer will depend on where you live in the world. There are others that share the same abbreviation as well. But CST is the one that constantly causes trouble in daily life. Just say no.
Re: Timezone Bullshit
#10> Let's take take a look, using the disastrously bad unix libc timezone tools Are there any more examples of them causing issues to warrant being called "disastrously bad"? This post just seems to have one example of bad error handling when they the TZ env var is set incorrectly. I'm genuinely interested if they actually are bad since they are used a lot.
They usually work because people check and notice mistakes. It gets worse now that you have countries next to each other that are out of sync on daylight saving - America/Los Angeles doesn’t work for those south of the border anymore - but you won’t notice except two weeks a year. Strangely I’ve noticed some systems give you WAY more cities than in the standard library - and I’m not sure why. Linode had way more opti…
Before about 1920, many US cities had their own time. Since then, there are far fewer time zones, mostly uniform across states, and named after a large city. Similarly in other countries. The large version of the database is only needed if you're trying to print very old dates.