Another reason not to use EST/EDT is that they are overspecifying the time zone in most cases. If you ask for output in EDT, but the date is in December (which is not part of daylight savings time) then should the date output be UTC-4 or UTC-5? Technically you asked for EDT.<p>Using EST as a shortcut isn’t a good idea, either - most software will “know what you mean” and use EST or EDT appropriately... except, both The USA and Canada have been toying with the idea of dropping daylight savings time, so it’s very possible at some point in the future that 6:00pm on July 1st will be EDT in America/New York, but EST in America/Montreal (or vice versa). This is already true for CST - Saskatchewan doesn’t use DST. And there have been times where one country or another changes the start date or end date of DST too, so there’s no reason to assume those will always be the same between Canada and the US.
The 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.<p>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.<p>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.<p>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.<p>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.
'There is no good reason to use short timezone codes like EST, CST, PST — doing so will only bring you pain. Either use the tzdb name like America/New_York, or use an offset from UTC, depending on what you want.'<p>All you need to read/remember is this, this applies everywhere not just with date.
The problem highlighted here causes one of the few gripes I have with PostgreSQL, and its logging capabilities in particular: It seems to only support logging time in one single format, which does contain a timezone identifier - but using the potentially ambiguous shorthand name.<p>A few moons ago, that led me down a whole new rabbit hole of its own that is Golang's time zone parsing capabilities (<a href="https://github.com/golang/go/issues/9617" rel="nofollow">https://github.com/golang/go/issues/9617</a>), which, at least for Elastic's filebeat, seem to vary at runtime depending on whether or not you have a time zone database available...<p>Moral of the story: Please just conform to ISO-8601 everywhere.
I'm still hoping .beat time[1] will catch on but I have been waiting since 1998... I even made a watch-face for my smartwatch showing .beats<p>[1] <a href="https://en.wikipedia.org/wiki/Swatch_Internet_Time" rel="nofollow">https://en.wikipedia.org/wiki/Swatch_Internet_Time</a>
> There are actually two timezones that are canonically named "CST", and they're 14 hours apart!<p>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.
Many years ago USPS provided a data stream that included every sorting machine operation a mail piece went through, the location it occurred (zip code), and the local time (sans timezone information). That was an absolute nightmare of a project that always had a few weekly cases of letters somehow time-traveling. Also, I was surprised to learn that there are sort facilities on tribal lands - I was not surprised to learn that they elected to record time differently from the state that surrounded them.
On macOS (Catalina-10.15.7), it looks like it is fixed or uses an updated version of the libc library mentioned in the article<p>Expected:<p>$ TZ=LOL_THIS_DOESNT_EXIST date
Sat 10 Jul 2021 12:00:00 AM LOL<p>Actual:<p>$ TZ=LOL_THIS_DOESNT_EXIST date
Wed Feb 10 17:02:02 UTC 2021<p>Otherwise I agree with the article. Have told so many co-workers that storing your dates in anything other than UTC will bite you in the ass later on. Converting it to the relevant time zone for display purposes is a trivial operation.
> Either use the tzdb name like America/New_York, or use an offset from UTC, depending on what you want.<p>I bet storing an offset is far more pain, given that anyone in a DST area will have 2 offsets per year.
The part about "using the text of the invalid timezone" seems to be fixed in latest GNU date (8.32):<p><pre><code> $ TZ=EDT gdate
Wed Feb 10 13:22:23 UTC 2021
$ gdate --version
date (GNU coreutils) 8.32
...
</code></pre>
8.30 (shipped in debian buster) still has the problem.<p>The BSD version of <i>date</i> shipped with MacOS 10.15 also does not seem to have this bug.
> Let's take take a look, using the disastrously bad unix libc timezone tools<p>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.<p>I'm genuinely interested if they actually are bad since they are used a lot.
Man, as a European this confuses the shit out of me. EST/CST and friends are nearly meaningless because I don't even know if the time I'm looking at is or supposed to be DST adjusted...
I work with a proprietary programming language that internally models a <i>date_time</i> as a UNIX epoch offset. The <i>to_string</i> method of a <i>date_time</i> results in a nice human readable string in the local timezone, but crucially not including the TZ itself. There were also accessors for the HH:MM:SS parts of the <i>date_time</i>.<p>At some point, the problem must've come up "if it's 5pm here in SFO, what time is it in MIA?", or some variation on that theme.<p>Someone decided that the best way to answer this was to write a function that took a <i>date_time</i>, then altered it to apply an offset between timezones. e.g. <i>time_local_to_tz</i>.<p>So you can could take a <i>date_time</i> in SFO, do <i>time_local_to_tz</i> (supplying Miami's TZ) and get back a <i>date_time</i> value that would <i>to_string</i> in SFO to show "the time in MIA". These functions made their way into a standard library and then to a lot of code.<p>The only problem is that the assumptions are literally all wrong. Adding the offset changes the actual point in time being addressed, which can change the timezone in effect in the current location, which results in the result skewing. This was compounded by some developers assuming that maybe they should convert their times to UTC before persisting them.<p>Of course, the usage of these functions is now embedded in a bunch of code no-one dares to touch, because it is full of hacks to "make it work" and quite possibly there is other code somewhere else (separated by a network connection, or a file, or persistence into a database) that is predicated on undoing those same set of hacks.
It's not just timezones names that are bullshit (they are!), the whole calendar is dumb.<p>Ideally the world should switch to an "earth calendar" where the year begins on the shortest day (currently Dec 21st for 90% of the population) and there are four yearly planet-wide holidays:<p>1. northern solstice<p>2. southern solstice<p>3. northward equinox<p>4. southward equinox<p>While we are at it, we could also do something more clever than months, weeks and the time system. 24/60/60 is a pain.
When I use the "full" timezone name like "America/New_York", how does libc resolve the ambiguity during the extra hour of the transition from daylight saving time to standard time?
Falsehoods Programmers believe about Time
<a href="https://news.ycombinator.com/item?id=4128208" rel="nofollow">https://news.ycombinator.com/item?id=4128208</a>
Really disappointed that the author did not want to delve into TZ dark magic:<p><pre><code> $ date && TZ=LOLS-3:03:03LOLD,J101,J202 date
Wed Feb 10 17:44:44 EST 2021
Thu Feb 11 01:47:47 LOLS 2021
</code></pre>
(My timezone is LOL Standard Time (LOLS), UTC+03:03:03, with support for changing to LOL Daylight Time (LOLD) during daylight savings, entering LOLD on the 101st Julian day of the calendar, and leaving on the 202nd Julian day of the calendar, excluding February 29th even in leap years.)
Is there a way to know which timezone (e.g. America/Phoenix) I'm in right now?<p>I did actually missed a meeting due to that. I was in small city in Montana, checked list of these timezones, but didn't know which one to choose. So I saw Phoenix has the same time as me, and set it at my device.<p>However, turned out that Montana actually uses America/Denver (which is Colorado) as their timezone. Is there a way to know that?
Time calculation is deceptively hard.<p>Here's a fun one: are timezones a mathematical construct or a physical construct? By which I mean: is the core of the problem to get the math right or to account for the geography of the planet?<p>It's a trick question. Timezones are a political construct. If your software is using timezones, it needs to somehow(1) account for changes to law, internationally. Individual countries can choose, for example, to use or stop using daylight savings time. Some have even chosen to shift the longitudinal timezone they consider themselves to be in.<p>(1) practically speaking, relying on tzdata (<a href="https://en.wikipedia.org/wiki/Tz_database" rel="nofollow">https://en.wikipedia.org/wiki/Tz_database</a>) is a great solution to this problem for most use cases... But you need to keep your copy of it updated, because laws change.
Another mistake I’ve seen is using one timezone code used interchangeably with others in the “same” timezone. This is bad because different locales have different DST rules, and because they have different governing authorities which can and do change the rules.<p>And another still: assuming that all of a state uses the same TZ. Quite a few do not! Arizona for instance has several tribal timezones which honor DST while the state does not. Nevada has a little sliver of mountain time. Michigan has four counties in central time. And so on.<p>This stuff is hard to get right. And it’s important. “Just use UTC” is often the naive solution but it’s not good enough for a variety of use cases.
Can I just say how grateful I am for good date/time/timezone libraries? Ok, this here library may not be a very good example - but imagine having to write and maintain all that stuff by yourself...
I cringe every time someone send me an email that says "I can meet at 10 PST" no matter what time of the year it is. But what can you do.<p>As far as the unix utilities go, the behavior is non-intuitive for sure, but can probably never be changed without breaking massive amounts of existing systems. The behavior is also reasonable considering the system constraints at the time it was written. Consulting an ever changing tz database every time the command runs was not an option, and maybe isn't even today.
I wish, although I'm totally aware it'll never happen, that there were no time zones, just UTC and that's it.<p>One clock for the world. If that meant you started work at 0900 UTC and finished at 1700 UTC then fine, but if you lived in a different part of the world your work day might be 0100-0900.<p>It'd definitely take a bit of getting used to, but as the world becomes more intertwined, timezones are a pain and constant source of confusion.
Rather than discrete time zones my ideal would be a continuous system which keeps sunrise at the same local time every day, backed by a universal coordinate system like UTC. "Dumb" clocks are set to UTC, "smart" clocks show local time and adjust daily. Sunrise at 8am, just go to bed at the end of the day (midnight) and you'll get a full rest. Call it Adjusted Local Time or something.
The other side of this is people assuming sydney time is brisbane or adelaide time, because they have limited experiental knowledge of a continent. we're well trained with mountain/central/eastern and Hawaii but we sometimes forget that LA is not next door to Chicago, I mean how far can it be?<p>Well.. Brisbane is not Sydney time. half the year we're 1 hour offset. AEST is not AEDT.
If you think that's bad, there are three distinct time zones which each go by CST.<p>And even Central Standard Time is ambiguous<p><a href="https://www.zainrizvi.io/blog/falsehoods-programmers-believe-about-time-zones#misconception-14-every-time-zone-has-its-own-abbreviation" rel="nofollow">https://www.zainrizvi.io/blog/falsehoods-programmers-believe...</a>
I always suspected the Whattimeisitrightnow.com joke on Bojack was inspired by a Sys Admin and hollywood writer getting drunk together.<p>Nice blog post.
What an important article to read. I've dealt over a decade with timezones, and this short article has shown me something new (EDT is not unique, gets silently set to UTC).<p>I am in the habit of using "Country/City" on everything that is not UTC, so I never encountered this issue. But it's so good to know.
I can't call someone in India without looking up their timezone and figuring out if they are at work or still sound asleep. Time zones made sense when the only people we could talk to lived close by.<p>Why not just use one universal time? At least we would know what time to agree on when planing a call. If I already have to look up the time zone in India before I call, it wouldn't be any harder to look up when people in India go to work or have lunch.<p>While we are at it I think we should move to a decimal time system. 100 seconds in minute, 100 minutes in hour, and 10 hours in a day. Naturally the second would be a bit shorter; the new seconds would be .864 current seconds. Then meetings could be scheduled in tenths of an hour, 0.2 hrs or 0.5 hrs etc.<p>We'd have to give this new world wide system a name, so that old time wouldn't be confused with new ones. I suggest saying something like 5.00-T8T (which stands for Todd8 Time) perfect!
Tom Scott did a fun video of the general nightmare that timezones bring to the dev table: <a href="https://youtu.be/-5wpm-gesOY" rel="nofollow">https://youtu.be/-5wpm-gesOY</a>
tzset(3) explains this. GNU is actually sort of bailing the author out in the unfortunate cases like America/New_York where it ignores you forgot to provide the prepending colon.<p>In terms of EDT, LOL, etc: again, well explained in the tzset manpage. EST works only because it appears the timezone database has EST and again, GNU is being helpful and assuming you meant to add the prepended colon.
> Let's take take a look, using the disastrously bad unix libc timezone tools<p>It seems to me that the author did not initially read the documentation they linked to (<a href="https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html" rel="nofollow">https://www.gnu.org/software/libc/manual/html_node/TZ-Variab...</a>) and is now complaining in an annoying and entitled manner.
<i>FACEPALM</i><p>It's not "EST", it's EST5EDT because the string "EST" shows up in other time zone designations. Learn time zones, then come back.
Obligatory post to <i>Computerphile</i> episode about Timezones - a must watch for developers just starting out with Timezones<p><a href="https://www.youtube.com/watch?v=-5wpm-gesOY" rel="nofollow">https://www.youtube.com/watch?v=-5wpm-gesOY</a>