21 ms·

Timezone Bullshit

400 points by organian 6y ago

rini17 6y ago
Tangentially, is there a standardized format for local time? ISO8601 has the same issue.
- tacostakohashi 6y ago
  What do you mean? ISO8601 specifies a number of formats. It also specifies how to include the timezone/offset, and that not mentioning a timezone means local time.
  - rini17 6y ago
    So how do I properly serialize a datetime in Europe/Prague time zone? As the article explains the use case where "CET" nor "CEST" nor fixed timezone offset is sufficient. And my actual local time zone is Europe/Bratislava, which may eventually differ from Prague.
    - eqvinox 6y ago
      I think this is out of scope for ISO 8601, especially since the "Europe/Bratislava" label is a specific reference to the tzdata tables. Another system may use another way of specifying the location for the time zone, e.g. GPS coordinates. (Though in practice I don't think anyone does that; literally everyone uses tzdata.) The "correct" way is presumably to work with an 8601 timestamp without time zone and carry the time zone spec along in an additional field.
      - rini17 6y ago
        I see. I have thought about using phone country/area codes. But they are now less relevant. Also, I remembered how I was on Canary islands - when left phone clock to auto synchronize, I got incorrect Madrid time.
bob1029 6y ago
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. 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.
- netsharc 6y ago
  Hmm, your applications don't have user input asking for a time?
  - soco 6y ago
    The GUI elements should have nothing to do with storing and interchanging timestamps. What you display can query the browser timezone to make it look nice, then send it down converted, over.
    - stefan_ 6y ago
      Ding ding ding, we got a winner. No, absolutely do not query the timezone once then "convert" (aka remove) the information. Timezones change all the time.
      - soco 6y ago
        There's a (fresh) extensive comment right above mine which explains the 4 different use cases for dates and the very minimal real need of TZ, let's all read it. Sorry I cannot comment otherwise your arguments because you didn't offer any.
sdm 6y ago
> 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.
- messe 6y ago
  As a support engineer living in Dublin “IST” is the bane of my life.
- soco 6y ago
  According to Wikipedia there are more than one overlappings: https://en.wikipedia.org/wiki/List_of_time_zone_abbreviations https://en.wikipedia.org/wiki/List_of_time_zone_abbreviation...
  - messe 6y ago
    I think BST, CST and IST are the only triple overlaps. I live in one and I'm adjacent to another.
- ycombobreaker 6y ago
  I find using the Olson DB names works in real life too--everybody understands "9AM Chicago" vs. "9AM Shanghai". Major international city names have fewer hash collisions than TZ abbreviations.
- javbit 6y ago
  I got bit by this when scheduling an interview. It's interesting because it's not that much harder to say America/Chicago (or just Chicago) but it's just by default I tend to say CST, CDT, etc. Started using UTC offsets but not many people know those off the top of their heads.
bolle 6y ago
Falsehoods Programmers believe about Time https://news.ycombinator.com/item?id=4128208 https://news.ycombinator.com/item?id=4128208
c0l0 6y ago
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. A few moons ago, that led me down a whole new rabbit hole of its own that is Golang's time zone parsing capabilities (https://github.com/golang/go/issues/9617 https://github.com/golang/go/issues/9617), which, at least for Elastic's filebeat, seem to vary at runtime depending on whether or not you have a time zone database available... Moral of the story: Please just conform to ISO-8601 everywhere.
- de_Selby 6y ago
  I'd say the moral is that server side should always be in UTC.
  - jnye131 6y ago
    OR.. should they be in TAI? https://en.wikipedia.org/wiki/International_Atomic_Time https://en.wikipedia.org/wiki/International_Atomic_Time
    - zaarn 6y ago
      Surprisingly, a bunch of software doesn't like it when you setup TAI, if you manage it to begin with.
  - NateEag 6y ago
    In some cases, storing times in UTC opens you up to possible errors: https://codeofmatt.com/on-the-timing-of-time-zone-changes/ https://codeofmatt.com/on-the-timing-of-time-zone-changes/ I think the right thing is to store times with the timezone the user wanted when they created the time. You can often use defaults or other UX niceties to streamline specifying TZ, but not always. Also, if you'll want to unambiguously know the timestamp's exact point in time at some point (like for comparison with other dayetimes), you should save the offset from UTC alongside the actual datetime. Otherwise, around clock changes like "fall back" you cannot tell if you're seeing 2 AM for the first or second time. This is the best I've come to trying to piece datetime storage together. If someone has better advice, I'd love to hear it. For more of my theory on timezone handling and the sources I've used to help me think it through, see http://howicode.nateeag.com/dates-and-times.html http://howicode.nateeag.com/dates-and-times.html .
rbanffy 6y ago
I believe the best move (literally) I ever made was to migrate from GMT-3 to (mostly) UTC.
jwalton 6y ago
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. 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.
- kenniskrag 6y ago
  > toying with the idea of dropping daylight Europeans turn back clocks for daylight saving, perhaps for last time. source: https://www.dw.com/en/europeans-turn-back-clocks-for-daylight-saving-perhaps-for-last-time/a-55389492 https://www.dw.com/en/europeans-turn-back-clocks-for-dayligh...
  - Hamuko 6y ago
    The EU DST debacle has been such a shitshow that I have trouble believing the words "perhaps for last time". And now with COVID-19, I haven't seen anyone actually focus on implementing the damn thing.
    - kenniskrag 6y ago
      What do you have to implement?
      - datejfktn 6y ago
        For once pretty much no one is aware of this supposed change. There was like a couple of articles on the day it was voted and that's it. This will 100% not happen, it's another one of those things that the EU parliament votes that everyone ignores, and it's perfect ammunition for those complaining that it makes laws without popular consultation. Trying to go forward with this change will generate massive anti EU backlash. And then you have the UK problem. Having variable time offsets between EU and UK would add yet another layer of disruption on top of Brexit.
sschueller 6y ago
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 [1] https://en.wikipedia.org/wiki/Swatch_Internet_Time https://en.wikipedia.org/wiki/Swatch_Internet_Time
- throwaway2245 6y ago
  I'm guessing (from your name and enthusiasm) that you live in a place where 0 approximately corresponds to midnight? :)
  - sschueller 6y ago
    Lunch at @500...
  - eCa 6y ago
    It would be more fair to split a week into 6000 parts, that way everyone would have midnight at strange ”hours” but on different days.
- joquarky 6y ago
  Another alternative is to base time on the current longitude of the solar meridian.
juddgaddie 6y ago
'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.' All you need to read/remember is this, this applies everywhere not just with date.
- arminiusreturns 6y ago
  The problem is peoples fascination with the S in the timezones, if you remove the S and the timezone equates to the proper, daylight savings adjusted +/- timezone according to the tz db. So instead of EST,CST,PST, use ET,CT,PT. For example ET equating to America/New_York, or as I prefer, US/Eastern. Traditional posix such as EST5EDT can have data gaps which cause issues that the tz db make up for, so in general: Just use UTC for most things. As with all things time, I'm no expert, and could be wrong about something. If you are, please correct me!
  - HideousKojima 6y ago
    >As with all things time, I'm no expert, and could be wrong about something. If you are, please correct me! Easy example that I have to deal with semi-regularly since I live and work in Mountain Time: Arizona. Arizona is under Mountain Time, but does not observe Daylight Savings. So America/Phoenix would work fine (and America/Denver for the rest of the Mountain Time zone) but simply using MT would not. To complicate matters even more is that the Navajo reservation (which is partially in Arizona) observes DST, but the Hopi Reservation (also in Arizona, but completely surrounded by the Navajo Reservation) does not.
- jonathanberger 6y ago
  Unfortunately the statement is not true. One good reason to use short timezone codes like EST, CST, PST is that most people prefer them. One of the first surprising things you learn after launching a timezone conversion website https://news.ycombinator.com/item?id=1133613 https://news.ycombinator.com/item?id=1133613 is that one of the top feature requests is to display short timezone codes.
grenoire 6y ago
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...
nelsonenzo 6y ago
I always suspected the Whattimeisitrightnow.com joke on Bojack was inspired by a Sys Admin and hollywood writer getting drunk together. Nice blog post.
de_Selby 6y ago
> 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.
- bombcar 6y ago
  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.
  - tlb 6y ago
    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.
phoronixrly 6y ago
> 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-Variable.html https://www.gnu.org/software/libc/manual/html_node/TZ-Variab...) and is now complaining in an annoying and entitled manner.
- biggerfisch 6y ago
  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"!
- steerablesafe 6y ago
  It's absolutely right to criticize insane behavior even if said behavior is documented. LOL "helpfully" being substituted to the output is absolutely insane.
  - phaemon 6y ago
    No it isn't. If you tell your computer that the timezone your machine is set to is called "LOL", then of course that's what it should report. What else would it do? It truncated the name because of the underscores, but you can do `TZ=somerandomthing date` to see it just reports what you say it is.
    - steerablesafe 6y ago
      Various behaviors when requesting time in a non-existent timezone: sane: report an error in some hard to ignore form less sane: ignore the provided timezone, display the time in UTC and properly mark it with "UTC" insane: ignore the provided timezone, display the time in UTC, but then mark it with the prefix of the provided timezone anyway. I don't care how well documented the insane behavior is, it's still insane.
NoOneNew 6y ago
Tom Scott did a fun video of the general nightmare that timezones bring to the dev table: https://youtu.be/-5wpm-gesOY https://youtu.be/-5wpm-gesOY
tal8d 6y ago
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.
Annatar 6y ago
FACEPALM It's not "EST", it's EST5EDT because the string "EST" shows up in other time zone designations. Learn time zones, then come back.
- deleted 6y ago
  [deleted]
Tepix 6y ago
It's not just timezones names that are bullshit (they are!), the whole calendar is dumb. 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: 1. northern solstice 2. southern solstice 3. northward equinox 4. southward equinox 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.
- BjoernKW 6y ago
  Part marketing ploy, part genuine attempt to improve time systems, especially in a global context, Swatch actually once tried to do so: https://en.m.wikipedia.org/wiki/Swatch_Internet_Time https://en.m.wikipedia.org/wiki/Swatch_Internet_Time Unfortunately, .beat time didn’t catch on.
  - iso1631 6y ago
    For most people, going to work on Monday and coming home on Tuesday isn't going to catch on (yes some of us work nights, it's rare)
- andruby 6y ago
  I have often wondered why 10 days after the shortest day was chosen to start the year (Jan 1). Does anyone know why they chose that?
k_sze 6y ago
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?
- Ayesh 6y ago
  Tzdb has the date and time that location starts/reverts DST. It is updated regularly to keep up with regions changing the time zones. It happens frequently than many of us like.
  - DavidPeiffer 6y ago
    I'm not sure I follow (and this week, timezones and time handling are really important for my job, so I really want to understand)! If a user provides a time of 11/7/2021 1:50 AM America/New_York, how does the library determine if it's a -5 or -4 offset given that's when daylight savings time ends? I believe that's the ambiguity GP is referring to. I'm trying to align time across a few systems I work with. One provides a GMT time with an offset (clean and useful), another system reports timezones and local time, and yet another system has no idea when it moves between time zones, but reports time based on a single timezone consistently. Not dealing with multiple timezones in the past, it reminds me of Tom Scott's video on handling time and timezones, summarized at the end as roughly "Go find someone who built a library for handling times, thank them profusely, use their open source code, give them credit, and never worry about it again." https://youtu.be/-5wpm-gesOY https://youtu.be/-5wpm-gesOY
    - k_sze 6y ago
      This also reminds me of the post Jon Skeet wrote about using UTC: https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/ https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a... Also discussed on HN back in the days: https://news.ycombinator.com/item?id=19500640 https://news.ycombinator.com/item?id=19500640
    - et-al 6y ago
      > If a user provides a time of 11/7/2021 1:50 AM America/New_York, how does the library determine if it's a -5 or -4 offset given that's when daylight savings time ends? Edit: I originally misunderstood your question. Since (in the future) 2021-11-07 02:00 is when we change to standard time, how does a library know whether to apply a -5 or -4 offset to 01:50? The library will need to make assumptions about the inputs and it would probably stick with the original offset (one should check the source). For a human-facing interface, it'd be a good idea to raise the issue.
7OVO7 6y ago
no standards = bullshit
qwertox 6y ago
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). 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.
- majewsky 6y ago
  Nitpick: "Continent/City".
  - jpitz 6y ago
    "America" isn't a continent.
    - treesprite82 6y ago
      America can be a continent. Definitions vary so sometimes it's split into "North America"/"South America", or pluralized "Americas". TZ database includes "America/Santiago" and "America/Sao_Paulo" so clearly it means the continent and not just the US.
      - jpitz 6y ago
        "The seven-continent model is usually taught in most English-speaking countries including the United States, United Kingdom[38] and Australia,[39] and also in China, India, Pakistan, the Philippines, and parts of Western Europe." https://en.wikipedia.org/wiki/Continent https://en.wikipedia.org/wiki/Continent Definitions do indeed vary, but that's how I learned it, and it would even seem to be the model most often taught. Which way were you taught?
NovemberWhiskey 6y ago
I work with a proprietary programming language that internally models a date_time as a UNIX epoch offset. The to_string method of a date_time 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 date_time. 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. Someone decided that the best way to answer this was to write a function that took a date_time, then altered it to apply an offset between timezones. e.g. time_local_to_tz. So you can could take a date_time in SFO, do time_local_to_tz (supplying Miami's TZ) and get back a date_time value that would to_string in SFO to show "the time in MIA". These functions made their way into a standard library and then to a lot of code. 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. 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.
- twic 6y ago
  I wrote an app that does a different but perhaps even more appalling crime. The app was for displaying time-series data. The data displayed was only generated during business hours. We usually wanted to view a span of a couple of weeks. Displaying it naively, with real time along the x-axis would mean that three-quarters of the display was blank, with only 40 of a week's 168 hours in use. The obvious thing to do is to elide the blank bits, and just show the spans of time with data (with a little gap in between). But the charting library i was using didn't have the concept of a discontinuous or nonlinear x-axis. So i wrote a class called TimeCompressor that would collect a set of time-series data, indexed by epoch timestamp, and rewrite the timestamps so that empty spans of time would be compressed. The earliest timestamp in the dataset stays the same, but later ones may be slid earlier in time to compress empty spans. The resulting indices are numbers which look mostly like epoch timestamps, and in some cases actually are epoch timestamps, but really aren't epoch timestamps. This was all done in JavaScript, so there wasn't a convenient way to wrap the not-really-timestamp indices in a type to mark them as such. So, in this application, when there's a field called somethingTimestamp and it has a large integer that looks like a timestamp in it, sometimes it's a timestamp, and sometimes it isn't! I am hoping this application will be retired before i ever need to work on it again.
cfstras 6y ago
The part about "using the text of the invalid timezone" seems to be fixed in latest GNU date (8.32): $ TZ=EDT gdate Wed Feb 10 13:22:23 UTC 2021 $ gdate --version date (GNU coreutils) 8.32 ... 8.30 (shipped in debian buster) still has the problem. The BSD version of date shipped with MacOS 10.15 also does not seem to have this bug.
- prussian 6y ago
  more likely the libc. I have the same version of GNU date using glibc and this behavior persists, as I would expect.
  - cfstras 6y ago
    ah, that makes sense. Looks like the gdate I'm using only links against libsystem, and I don't have a glibc anywhere. So it's the darwin libc that doesn't have this bug. Testing with https://hub.docker.com/_/busybox https://hub.docker.com/_/busybox, it seems like musl also has this problem. uclibc is not affected.
FabHK 6y ago
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...
larrik 6y ago
> Either use the tzdb name like America/New_York, or use an offset from UTC, depending on what you want. I bet storing an offset is far more pain, given that anyone in a DST area will have 2 offsets per year.
- shadowgovt 6y ago
  Offsets can very easily be the wrong answer (though the author is quite correct that it depends on what you're trying to do). If your user intends to use one of the timezones that has a daylight savings calculation, the offset changes as the year goes on. Offsets can also change if the definition of the timezone itself changes (Russia ceased to use daylight savings in 2014). Offsets can be useful if one is attempting to record a historical incident, where the timezone had a particular-defined offset at the point in time the incident occurred (though for my money, I'd just convert that time to UTC on storage).
- followben 6y ago
  This needs more upvotes.
protomyth 6y ago
Odd, I have been using CST6CDT on my OpenBSD servers. Is this not a normal construction?
- prussian 6y ago
  you'd have to constantly update your TZ to reflect changing transition periods, which you don't even specify. using a tzdata file, you get this for free plus proper transitions for older dates.
  - protomyth 6y ago
    Uhm... CST6CDT has zone info just like America/Chicago or America/New_York. What am I missing?
yboris 6y ago
Obligatory post to Computerphile episode about Timezones - a must watch for developers just starting out with Timezones https://www.youtube.com/watch?v=-5wpm-gesOY https://www.youtube.com/watch?v=-5wpm-gesOY
shadowgovt 6y ago
Time calculation is deceptively hard. 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? 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. (1) practically speaking, relying on tzdata (https://en.wikipedia.org/wiki/Tz_database https://en.wikipedia.org/wiki/Tz_database) is a great solution to this problem for most use cases... But you need to keep your copy of it updated, because laws change.
xyst 6y ago
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 Expected: $ TZ=LOL_THIS_DOESNT_EXIST date Sat 10 Jul 2021 12:00:00 AM LOL Actual: $ TZ=LOL_THIS_DOESNT_EXIST date Wed Feb 10 17:02:02 UTC 2021 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.
- exporectomy 6y ago
  It's not as simple as UTC everywhere. If you're representing a fixed point in time, independent of any local time, then yes. But sometimes, a date/time is relative to the local time zone and in those cases, the local time zone is the correct one to store it in. For example, scheduled times for future events in the real world such as appointments. You can't store it as UTC because you can't know what the time zone offset will be in the future since that's a political decision.
eyelidlessness 6y ago
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. 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. 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.
deleted 6y ago
[deleted]
ZainRiz 6y ago
If you think that's bad, there are three distinct time zones which each go by CST. And even Central Standard Time is ambiguous https://www.zainrizvi.io/blog/falsehoods-programmers-believe-about-time-zones#misconception-14-every-time-zone-has-its-own-abbreviation https://www.zainrizvi.io/blog/falsehoods-programmers-believe...
prussian 6y ago
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. 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.
ggm 6y ago
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? Well.. Brisbane is not Sydney time. half the year we're 1 hour offset. AEST is not AEDT.
deepsun 6y ago
Is there a way to know which timezone (e.g. America/Phoenix) I'm in right now? 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. However, turned out that Montana actually uses America/Denver (which is Colorado) as their timezone. Is there a way to know that?
- cwmma 6y ago
  the general rule of thumb for American Timezones is that Arizona is its own special thing and as long as you stay out of that state then you're in America/{los_angeles|denver|chicago|new_york} for pacific, mountain, central, and eastern respectively. Just stay away from Arizona and American time zones are easy and what you did would work. Arizona is special because it's in mountain time, it doesn't observer daylight saving time so half the year it has the same time as pacific time except for the Navajo Nation which does observe daylight saving time but the Hopi Nation which is entirely inside the Navajo Nation doesn't follow daylight saving. edit: picture of the Arizona timezone situation https://en.wikipedia.org/wiki/Time_in_Arizona#/media/File:Arizona_Daylight_Savings_Time_map.svg https://en.wikipedia.org/wiki/Time_in_Arizona#/media/File:Ar...
  - deepsun 6y ago
    Thank you. What about the rest of the Earth?
jacobsenscott 6y ago
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. 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.
- jackson1442 6y ago
  > 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. Why? An average person (read: non-developer) rarely needs to think about their timezone, save for when it changes. As a human, it seems relatively straightforward to intuitively determine whether that person is in DST or not. If you were a UNIX machine (or a developer providing input to one such machine, I guess), it might be more appropriate to ask for a response in the Americas/Chicago format or something like UTC-0600, but it seems rather coarse to require that everyone adhere to your personal timezone standards when interacting with you. Personally, I frequently schedule meetings with clients all over the US where their timezone isn't necessarily clear to me, so I usually just say something along the lines of "1045am CT," omitting the S/D in its entirety.
  - Dylan16807 6y ago
    > As a human, it seems relatively straightforward to intuitively determine whether that person is in DST or not. But you don't know if someone used a calculator and invoked actual PST during the summer. > I usually just say something along the lines of "1045am CT," omitting the S/D in its entirety. Good.
  - jacobsenscott 6y ago
    I cringe because I've dealt with so many timezone bugs, because it is notoriously hard to get right. So it is just sort of a PTSD reaction. Of course I know what they mean, I just cringe to myself.
  - 6y ago
apaprocki 6y ago
Really disappointed that the author did not want to delve into TZ dark magic: $ 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 (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.)
- dan-robertson 6y ago
  I find this magic quite unpleasant. It causes a massive amount of confusion (eg if you write TZ=UTC+8, you actually get UTC-8, except it’s called UTC. You’d actually need to type eg TZ=XYZ-8 because you subtract 8 hours to get UTC. The theory at the time was that it made it easier to enter US timezones like UTC-5.) Furthermore, some applications won’t parse a timezone that isn’t in the local tzdb so you’d actually need to enter eg TZ=Etc/GMT-8 for UTC+8. And heaven forfend an application might parse TZ=UTC+8 in the “normal” way instead of the posix way. What a recipe for disaster. Encoding daylight savings in the env var just makes the whole mess worse.
Floegipoky 6y ago
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.
- davidgtl 6y ago
  everything is discrete if you look fine enough. locally (household-fine) what you say would be nice, however the moment you start travelling informational nightmares would ensue due to human nature, nobody (in the grand scheme) would use the UTC time since local is more useful/frequent so all travellers need translators which can seamlessly translate local time to be as useful as current narional timezones are. such a translator would either be manually preprogrammed(cumbersome) or GPS, computer-powered which brings its own troubles. I think countrywide(as in european country or american state) is a pretty good scale tradedoff between ease of use and accuracy which is here to stay until GPS and computation are ubiquitous(as in every grandma has access to a smart device with GPS she can leave on all day and can be read as easily as a wall clock while having dough all over her hands) sorriez for wall of text :)
todd8 6y ago
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. 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. 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. 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!
- smilekzs 6y ago
  see also https://en.wikipedia.org/wiki/Decimal_time https://en.wikipedia.org/wiki/Decimal_time in case this is not "/s"
  - todd8 6y ago
    Oh, thanks. That's interesting, there's a long history of decimal time. Afer fixing the time we can fix the calendar. See the Hanke–Henry Permanent Calendar at https://en.wikipedia.org/wiki/Hanke–Henry_Permanent_Calendar https://en.wikipedia.org/wiki/Hanke–Henry_Permanent_Calendar
- kanzenryu2 6y ago
  I give you... http://www.swatchclock.com/ http://www.swatchclock.com/
ehwhyreally 6y ago
not this again. every one hates timezones. they are poorly designed and incorrect to begin with. move on.
a5withtrrs 6y ago
I wish, although I'm totally aware it'll never happen, that there were no time zones, just UTC and that's it. 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. 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.

Timezone Bullshit

400 points by organian 6y ago

rini17 6y ago

Tangentially, is there a standardized format for local time? ISO8601 has the same issue.

tacostakohashi 6y ago
What do you mean? ISO8601 specifies a number of formats. It also specifies how to include the timezone/offset, and that not mentioning a timezone means local time.
- rini17 6y ago
  So how do I properly serialize a datetime in Europe/Prague time zone? As the article explains the use case where "CET" nor "CEST" nor fixed timezone offset is sufficient. And my actual local time zone is Europe/Bratislava, which may eventually differ from Prague.
  - eqvinox 6y ago
    I think this is out of scope for ISO 8601, especially since the "Europe/Bratislava" label is a specific reference to the tzdata tables. Another system may use another way of specifying the location for the time zone, e.g. GPS coordinates. (Though in practice I don't think anyone does that; literally everyone uses tzdata.) The "correct" way is presumably to work with an 8601 timestamp without time zone and carry the time zone spec along in an additional field.
    - rini17 6y ago
      I see. I have thought about using phone country/area codes. But they are now less relevant. Also, I remembered how I was on Canary islands - when left phone clock to auto synchronize, I got incorrect Madrid time.

bob1029 6y ago

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

netsharc 6y ago
Hmm, your applications don't have user input asking for a time?
- soco 6y ago
  The GUI elements should have nothing to do with storing and interchanging timestamps. What you display can query the browser timezone to make it look nice, then send it down converted, over.
  - stefan_ 6y ago
    Ding ding ding, we got a winner. No, absolutely do not query the timezone once then "convert" (aka remove) the information. Timezones change all the time.
    - soco 6y ago
      There's a (fresh) extensive comment right above mine which explains the 4 different use cases for dates and the very minimal real need of TZ, let's all read it. Sorry I cannot comment otherwise your arguments because you didn't offer any.

sdm 6y ago

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

messe 6y ago
As a support engineer living in Dublin “IST” is the bane of my life.
soco 6y ago
According to Wikipedia there are more than one overlappings: https://en.wikipedia.org/wiki/List_of_time_zone_abbreviations https://en.wikipedia.org/wiki/List_of_time_zone_abbreviation...
- messe 6y ago
  I think BST, CST and IST are the only triple overlaps. I live in one and I'm adjacent to another.
ycombobreaker 6y ago
I find using the Olson DB names works in real life too--everybody understands "9AM Chicago" vs. "9AM Shanghai". Major international city names have fewer hash collisions than TZ abbreviations.
javbit 6y ago
I got bit by this when scheduling an interview. It's interesting because it's not that much harder to say America/Chicago (or just Chicago) but it's just by default I tend to say CST, CDT, etc. Started using UTC offsets but not many people know those off the top of their heads.

bolle 6y ago

Falsehoods Programmers believe about Time https://news.ycombinator.com/item?id=4128208 https://news.ycombinator.com/item?id=4128208

c0l0 6y ago

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. A few moons ago, that led me down a whole new rabbit hole of its own that is Golang's time zone parsing capabilities (https://github.com/golang/go/issues/9617 https://github.com/golang/go/issues/9617), which, at least for Elastic's filebeat, seem to vary at runtime depending on whether or not you have a time zone database available... Moral of the story: Please just conform to ISO-8601 everywhere.

de_Selby 6y ago
I'd say the moral is that server side should always be in UTC.
- jnye131 6y ago
  OR.. should they be in TAI? https://en.wikipedia.org/wiki/International_Atomic_Time https://en.wikipedia.org/wiki/International_Atomic_Time
  - zaarn 6y ago
    Surprisingly, a bunch of software doesn't like it when you setup TAI, if you manage it to begin with.
- NateEag 6y ago
  In some cases, storing times in UTC opens you up to possible errors: https://codeofmatt.com/on-the-timing-of-time-zone-changes/ https://codeofmatt.com/on-the-timing-of-time-zone-changes/ I think the right thing is to store times with the timezone the user wanted when they created the time. You can often use defaults or other UX niceties to streamline specifying TZ, but not always. Also, if you'll want to unambiguously know the timestamp's exact point in time at some point (like for comparison with other dayetimes), you should save the offset from UTC alongside the actual datetime. Otherwise, around clock changes like "fall back" you cannot tell if you're seeing 2 AM for the first or second time. This is the best I've come to trying to piece datetime storage together. If someone has better advice, I'd love to hear it. For more of my theory on timezone handling and the sources I've used to help me think it through, see http://howicode.nateeag.com/dates-and-times.html http://howicode.nateeag.com/dates-and-times.html .

rbanffy 6y ago

I believe the best move (literally) I ever made was to migrate from GMT-3 to (mostly) UTC.

jwalton 6y ago

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

kenniskrag 6y ago
> toying with the idea of dropping daylight Europeans turn back clocks for daylight saving, perhaps for last time. source: https://www.dw.com/en/europeans-turn-back-clocks-for-daylight-saving-perhaps-for-last-time/a-55389492 https://www.dw.com/en/europeans-turn-back-clocks-for-dayligh...
- Hamuko 6y ago
  The EU DST debacle has been such a shitshow that I have trouble believing the words "perhaps for last time". And now with COVID-19, I haven't seen anyone actually focus on implementing the damn thing.
  - kenniskrag 6y ago
    What do you have to implement?
    - datejfktn 6y ago
      For once pretty much no one is aware of this supposed change. There was like a couple of articles on the day it was voted and that's it. This will 100% not happen, it's another one of those things that the EU parliament votes that everyone ignores, and it's perfect ammunition for those complaining that it makes laws without popular consultation. Trying to go forward with this change will generate massive anti EU backlash. And then you have the UK problem. Having variable time offsets between EU and UK would add yet another layer of disruption on top of Brexit.

sschueller 6y ago

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 [1] https://en.wikipedia.org/wiki/Swatch_Internet_Time https://en.wikipedia.org/wiki/Swatch_Internet_Time

throwaway2245 6y ago
I'm guessing (from your name and enthusiasm) that you live in a place where 0 approximately corresponds to midnight? :)
- sschueller 6y ago
  Lunch at @500...
- eCa 6y ago
  It would be more fair to split a week into 6000 parts, that way everyone would have midnight at strange ”hours” but on different days.
joquarky 6y ago
Another alternative is to base time on the current longitude of the solar meridian.

juddgaddie 6y ago

'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.' All you need to read/remember is this, this applies everywhere not just with date.

arminiusreturns 6y ago
The problem is peoples fascination with the S in the timezones, if you remove the S and the timezone equates to the proper, daylight savings adjusted +/- timezone according to the tz db. So instead of EST,CST,PST, use ET,CT,PT. For example ET equating to America/New_York, or as I prefer, US/Eastern. Traditional posix such as EST5EDT can have data gaps which cause issues that the tz db make up for, so in general: Just use UTC for most things. As with all things time, I'm no expert, and could be wrong about something. If you are, please correct me!
- HideousKojima 6y ago
  >As with all things time, I'm no expert, and could be wrong about something. If you are, please correct me! Easy example that I have to deal with semi-regularly since I live and work in Mountain Time: Arizona. Arizona is under Mountain Time, but does not observe Daylight Savings. So America/Phoenix would work fine (and America/Denver for the rest of the Mountain Time zone) but simply using MT would not. To complicate matters even more is that the Navajo reservation (which is partially in Arizona) observes DST, but the Hopi Reservation (also in Arizona, but completely surrounded by the Navajo Reservation) does not.
jonathanberger 6y ago
Unfortunately the statement is not true. One good reason to use short timezone codes like EST, CST, PST is that most people prefer them. One of the first surprising things you learn after launching a timezone conversion website https://news.ycombinator.com/item?id=1133613 https://news.ycombinator.com/item?id=1133613 is that one of the top feature requests is to display short timezone codes.

grenoire 6y ago

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

nelsonenzo 6y ago

I always suspected the Whattimeisitrightnow.com joke on Bojack was inspired by a Sys Admin and hollywood writer getting drunk together. Nice blog post.

de_Selby 6y ago

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

bombcar 6y ago
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.
- tlb 6y ago
  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.

phoronixrly 6y ago

> 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-Variable.html https://www.gnu.org/software/libc/manual/html_node/TZ-Variab...) and is now complaining in an annoying and entitled manner.

biggerfisch 6y ago
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"!
steerablesafe 6y ago
It's absolutely right to criticize insane behavior even if said behavior is documented. LOL "helpfully" being substituted to the output is absolutely insane.
- phaemon 6y ago
  No it isn't. If you tell your computer that the timezone your machine is set to is called "LOL", then of course that's what it should report. What else would it do? It truncated the name because of the underscores, but you can do `TZ=somerandomthing date` to see it just reports what you say it is.
  - steerablesafe 6y ago
    Various behaviors when requesting time in a non-existent timezone: sane: report an error in some hard to ignore form less sane: ignore the provided timezone, display the time in UTC and properly mark it with "UTC" insane: ignore the provided timezone, display the time in UTC, but then mark it with the prefix of the provided timezone anyway. I don't care how well documented the insane behavior is, it's still insane.

NoOneNew 6y ago

Tom Scott did a fun video of the general nightmare that timezones bring to the dev table: https://youtu.be/-5wpm-gesOY https://youtu.be/-5wpm-gesOY

tal8d 6y ago

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.

Annatar 6y ago

FACEPALM It's not "EST", it's EST5EDT because the string "EST" shows up in other time zone designations. Learn time zones, then come back.

deleted 6y ago
[deleted]

Tepix 6y ago

It's not just timezones names that are bullshit (they are!), the whole calendar is dumb. 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: 1. northern solstice 2. southern solstice 3. northward equinox 4. southward equinox 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.

BjoernKW 6y ago
Part marketing ploy, part genuine attempt to improve time systems, especially in a global context, Swatch actually once tried to do so: https://en.m.wikipedia.org/wiki/Swatch_Internet_Time https://en.m.wikipedia.org/wiki/Swatch_Internet_Time Unfortunately, .beat time didn’t catch on.
- iso1631 6y ago
  For most people, going to work on Monday and coming home on Tuesday isn't going to catch on (yes some of us work nights, it's rare)
andruby 6y ago
I have often wondered why 10 days after the shortest day was chosen to start the year (Jan 1). Does anyone know why they chose that?

k_sze 6y ago

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?

Ayesh 6y ago
Tzdb has the date and time that location starts/reverts DST. It is updated regularly to keep up with regions changing the time zones. It happens frequently than many of us like.
- DavidPeiffer 6y ago
  I'm not sure I follow (and this week, timezones and time handling are really important for my job, so I really want to understand)! If a user provides a time of 11/7/2021 1:50 AM America/New_York, how does the library determine if it's a -5 or -4 offset given that's when daylight savings time ends? I believe that's the ambiguity GP is referring to. I'm trying to align time across a few systems I work with. One provides a GMT time with an offset (clean and useful), another system reports timezones and local time, and yet another system has no idea when it moves between time zones, but reports time based on a single timezone consistently. Not dealing with multiple timezones in the past, it reminds me of Tom Scott's video on handling time and timezones, summarized at the end as roughly "Go find someone who built a library for handling times, thank them profusely, use their open source code, give them credit, and never worry about it again." https://youtu.be/-5wpm-gesOY https://youtu.be/-5wpm-gesOY
  - k_sze 6y ago
    This also reminds me of the post Jon Skeet wrote about using UTC: https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/ https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a... Also discussed on HN back in the days: https://news.ycombinator.com/item?id=19500640 https://news.ycombinator.com/item?id=19500640
  - et-al 6y ago
    > If a user provides a time of 11/7/2021 1:50 AM America/New_York, how does the library determine if it's a -5 or -4 offset given that's when daylight savings time ends? Edit: I originally misunderstood your question. Since (in the future) 2021-11-07 02:00 is when we change to standard time, how does a library know whether to apply a -5 or -4 offset to 01:50? The library will need to make assumptions about the inputs and it would probably stick with the original offset (one should check the source). For a human-facing interface, it'd be a good idea to raise the issue.

7OVO7 6y ago

no standards = bullshit

qwertox 6y ago

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

majewsky 6y ago
Nitpick: "Continent/City".
- jpitz 6y ago
  "America" isn't a continent.
  - treesprite82 6y ago
    America can be a continent. Definitions vary so sometimes it's split into "North America"/"South America", or pluralized "Americas". TZ database includes "America/Santiago" and "America/Sao_Paulo" so clearly it means the continent and not just the US.
    - jpitz 6y ago
      "The seven-continent model is usually taught in most English-speaking countries including the United States, United Kingdom[38] and Australia,[39] and also in China, India, Pakistan, the Philippines, and parts of Western Europe." https://en.wikipedia.org/wiki/Continent https://en.wikipedia.org/wiki/Continent Definitions do indeed vary, but that's how I learned it, and it would even seem to be the model most often taught. Which way were you taught?

NovemberWhiskey 6y ago

I work with a proprietary programming language that internally models a date_time as a UNIX epoch offset. The to_string method of a date_time 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 date_time. 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. Someone decided that the best way to answer this was to write a function that took a date_time, then altered it to apply an offset between timezones. e.g. time_local_to_tz. So you can could take a date_time in SFO, do time_local_to_tz (supplying Miami's TZ) and get back a date_time value that would to_string in SFO to show "the time in MIA". These functions made their way into a standard library and then to a lot of code. 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. 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.

twic 6y ago
I wrote an app that does a different but perhaps even more appalling crime. The app was for displaying time-series data. The data displayed was only generated during business hours. We usually wanted to view a span of a couple of weeks. Displaying it naively, with real time along the x-axis would mean that three-quarters of the display was blank, with only 40 of a week's 168 hours in use. The obvious thing to do is to elide the blank bits, and just show the spans of time with data (with a little gap in between). But the charting library i was using didn't have the concept of a discontinuous or nonlinear x-axis. So i wrote a class called TimeCompressor that would collect a set of time-series data, indexed by epoch timestamp, and rewrite the timestamps so that empty spans of time would be compressed. The earliest timestamp in the dataset stays the same, but later ones may be slid earlier in time to compress empty spans. The resulting indices are numbers which look mostly like epoch timestamps, and in some cases actually are epoch timestamps, but really aren't epoch timestamps. This was all done in JavaScript, so there wasn't a convenient way to wrap the not-really-timestamp indices in a type to mark them as such. So, in this application, when there's a field called somethingTimestamp and it has a large integer that looks like a timestamp in it, sometimes it's a timestamp, and sometimes it isn't! I am hoping this application will be retired before i ever need to work on it again.

cfstras 6y ago

The part about "using the text of the invalid timezone" seems to be fixed in latest GNU date (8.32): $ TZ=EDT gdate Wed Feb 10 13:22:23 UTC 2021 $ gdate --version date (GNU coreutils) 8.32 ... 8.30 (shipped in debian buster) still has the problem. The BSD version of date shipped with MacOS 10.15 also does not seem to have this bug.

prussian 6y ago
more likely the libc. I have the same version of GNU date using glibc and this behavior persists, as I would expect.
- cfstras 6y ago
  ah, that makes sense. Looks like the gdate I'm using only links against libsystem, and I don't have a glibc anywhere. So it's the darwin libc that doesn't have this bug. Testing with https://hub.docker.com/_/busybox https://hub.docker.com/_/busybox, it seems like musl also has this problem. uclibc is not affected.

FabHK 6y ago

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

larrik 6y ago

> Either use the tzdb name like America/New_York, or use an offset from UTC, depending on what you want. I bet storing an offset is far more pain, given that anyone in a DST area will have 2 offsets per year.

shadowgovt 6y ago
Offsets can very easily be the wrong answer (though the author is quite correct that it depends on what you're trying to do). If your user intends to use one of the timezones that has a daylight savings calculation, the offset changes as the year goes on. Offsets can also change if the definition of the timezone itself changes (Russia ceased to use daylight savings in 2014). Offsets can be useful if one is attempting to record a historical incident, where the timezone had a particular-defined offset at the point in time the incident occurred (though for my money, I'd just convert that time to UTC on storage).
followben 6y ago
This needs more upvotes.

protomyth 6y ago

Odd, I have been using CST6CDT on my OpenBSD servers. Is this not a normal construction?

prussian 6y ago
you'd have to constantly update your TZ to reflect changing transition periods, which you don't even specify. using a tzdata file, you get this for free plus proper transitions for older dates.
- protomyth 6y ago
  Uhm... CST6CDT has zone info just like America/Chicago or America/New_York. What am I missing?

yboris 6y ago

Obligatory post to Computerphile episode about Timezones - a must watch for developers just starting out with Timezones https://www.youtube.com/watch?v=-5wpm-gesOY https://www.youtube.com/watch?v=-5wpm-gesOY

shadowgovt 6y ago

Time calculation is deceptively hard. 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? 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. (1) practically speaking, relying on tzdata (https://en.wikipedia.org/wiki/Tz_database https://en.wikipedia.org/wiki/Tz_database) is a great solution to this problem for most use cases... But you need to keep your copy of it updated, because laws change.

xyst 6y ago

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 Expected: $ TZ=LOL_THIS_DOESNT_EXIST date Sat 10 Jul 2021 12:00:00 AM LOL Actual: $ TZ=LOL_THIS_DOESNT_EXIST date Wed Feb 10 17:02:02 UTC 2021 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.

exporectomy 6y ago
It's not as simple as UTC everywhere. If you're representing a fixed point in time, independent of any local time, then yes. But sometimes, a date/time is relative to the local time zone and in those cases, the local time zone is the correct one to store it in. For example, scheduled times for future events in the real world such as appointments. You can't store it as UTC because you can't know what the time zone offset will be in the future since that's a political decision.

eyelidlessness 6y ago

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

deleted 6y ago

[deleted]

ZainRiz 6y ago

If you think that's bad, there are three distinct time zones which each go by CST. And even Central Standard Time is ambiguous https://www.zainrizvi.io/blog/falsehoods-programmers-believe-about-time-zones#misconception-14-every-time-zone-has-its-own-abbreviation https://www.zainrizvi.io/blog/falsehoods-programmers-believe...

prussian 6y ago

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

ggm 6y ago

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? Well.. Brisbane is not Sydney time. half the year we're 1 hour offset. AEST is not AEDT.

deepsun 6y ago

Is there a way to know which timezone (e.g. America/Phoenix) I'm in right now? 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. However, turned out that Montana actually uses America/Denver (which is Colorado) as their timezone. Is there a way to know that?

cwmma 6y ago
the general rule of thumb for American Timezones is that Arizona is its own special thing and as long as you stay out of that state then you're in America/{los_angeles|denver|chicago|new_york} for pacific, mountain, central, and eastern respectively. Just stay away from Arizona and American time zones are easy and what you did would work. Arizona is special because it's in mountain time, it doesn't observer daylight saving time so half the year it has the same time as pacific time except for the Navajo Nation which does observe daylight saving time but the Hopi Nation which is entirely inside the Navajo Nation doesn't follow daylight saving. edit: picture of the Arizona timezone situation https://en.wikipedia.org/wiki/Time_in_Arizona#/media/File:Arizona_Daylight_Savings_Time_map.svg https://en.wikipedia.org/wiki/Time_in_Arizona#/media/File:Ar...
- deepsun 6y ago
  Thank you. What about the rest of the Earth?

jacobsenscott 6y ago

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

jackson1442 6y ago
> 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. Why? An average person (read: non-developer) rarely needs to think about their timezone, save for when it changes. As a human, it seems relatively straightforward to intuitively determine whether that person is in DST or not. If you were a UNIX machine (or a developer providing input to one such machine, I guess), it might be more appropriate to ask for a response in the Americas/Chicago format or something like UTC-0600, but it seems rather coarse to require that everyone adhere to your personal timezone standards when interacting with you. Personally, I frequently schedule meetings with clients all over the US where their timezone isn't necessarily clear to me, so I usually just say something along the lines of "1045am CT," omitting the S/D in its entirety.
- Dylan16807 6y ago
  > As a human, it seems relatively straightforward to intuitively determine whether that person is in DST or not. But you don't know if someone used a calculator and invoked actual PST during the summer. > I usually just say something along the lines of "1045am CT," omitting the S/D in its entirety. Good.
- jacobsenscott 6y ago
  I cringe because I've dealt with so many timezone bugs, because it is notoriously hard to get right. So it is just sort of a PTSD reaction. Of course I know what they mean, I just cringe to myself.
- 6y ago

apaprocki 6y ago

Really disappointed that the author did not want to delve into TZ dark magic: $ 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 (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.)

dan-robertson 6y ago
I find this magic quite unpleasant. It causes a massive amount of confusion (eg if you write TZ=UTC+8, you actually get UTC-8, except it’s called UTC. You’d actually need to type eg TZ=XYZ-8 because you subtract 8 hours to get UTC. The theory at the time was that it made it easier to enter US timezones like UTC-5.) Furthermore, some applications won’t parse a timezone that isn’t in the local tzdb so you’d actually need to enter eg TZ=Etc/GMT-8 for UTC+8. And heaven forfend an application might parse TZ=UTC+8 in the “normal” way instead of the posix way. What a recipe for disaster. Encoding daylight savings in the env var just makes the whole mess worse.

Floegipoky 6y ago

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.

davidgtl 6y ago
everything is discrete if you look fine enough. locally (household-fine) what you say would be nice, however the moment you start travelling informational nightmares would ensue due to human nature, nobody (in the grand scheme) would use the UTC time since local is more useful/frequent so all travellers need translators which can seamlessly translate local time to be as useful as current narional timezones are. such a translator would either be manually preprogrammed(cumbersome) or GPS, computer-powered which brings its own troubles. I think countrywide(as in european country or american state) is a pretty good scale tradedoff between ease of use and accuracy which is here to stay until GPS and computation are ubiquitous(as in every grandma has access to a smart device with GPS she can leave on all day and can be read as easily as a wall clock while having dough all over her hands) sorriez for wall of text :)

todd8 6y ago

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

smilekzs 6y ago
see also https://en.wikipedia.org/wiki/Decimal_time https://en.wikipedia.org/wiki/Decimal_time in case this is not "/s"
- todd8 6y ago
  Oh, thanks. That's interesting, there's a long history of decimal time. Afer fixing the time we can fix the calendar. See the Hanke–Henry Permanent Calendar at https://en.wikipedia.org/wiki/Hanke–Henry_Permanent_Calendar https://en.wikipedia.org/wiki/Hanke–Henry_Permanent_Calendar
kanzenryu2 6y ago
I give you... http://www.swatchclock.com/ http://www.swatchclock.com/

ehwhyreally 6y ago

not this again. every one hates timezones. they are poorly designed and incorrect to begin with. move on.

a5withtrrs 6y ago

I wish, although I'm totally aware it'll never happen, that there were no time zones, just UTC and that's it. 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. 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.