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.
On the topic of DST... can you explain why some countries use DST? Anytime I look for the reasoning of it, it says that DST helps "make better use of daytime" but how? The earth isn't gonna say "Damn! These people changed their clocks. I better change by rotation and give them more sun time." Whether you have DST or not, you still have the same amount of time with sunlight in a day.
I (living in California) usually use "PST8PDT", which does what I want, all year round (for some irrational reason I refuse to claim that I live in Los_Angeles[0]). I believe there's also "EST5EDT", "CST6CDT", and "MST7MDT" as well.
But agree that this is just a grab bag of confusing garbage.
[0] I suppose if CA does away with DST (or keeps it permanently), I will have to change...
> 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?
EST is always UTC-4 and EDT is always UTC-5. Both of these exist throughout the year. The only change happening in Spring/Autumn is that some places change which time zone they currently observe.
This also addresses the second problem that you outlined. As long as the query is properly specified (if you want information related to a location, use America/New York; if you want information related to a time zone, use the time zone), you can always get an unambiguous and correct answer.
> both The USA and Canada have been toying with the idea of dropping daylight savings time
Individual states are toying with the idea as well [1], which presents a problem if one of the tzdata locations decides to change its rules. You're screwed no matter what you choose to do. :-(
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.
Human-decided events in the future are an obvious example. E.g. "every second Tuesday at 8:00" or "May 17, 2025, 8:00" shouldn't ever happen at 7 or 9, even if your software didn't have accurate DST information for that point available initially (which countries do change, sometimes with only a few weeks of warning!).
> Trying to carry timezone information around is a mistake.
No.
If a human says a recurring meeting happens at 9 AM Pacific time and the following week they are in daylight saving time, it'll still happen at 9 AM local time. Preserving intent is crucial in this case.
Aside from issues of synchronization, leap seconds, data container limitations and such, it's important to choose the correct kind of time to store, and the right kind depends on what the purpose of recording the time is.
There are three main kinds of time:
*Absolute Time*
Absolute time is a time that is fixed relative to UTC (or relative to an offset from UTC). It is not affected by daylight savings time, nor will it ever change if an area's time zone changes for political reasons. Absolute time is best recorded in the UTC time zone, and is mostly useful for events in the past (because the time zone is now fixed at the time of the event, so it probably no longer matters what specific time zone was in effect).
*Fixed Time*
Fixed time is a time that is fixed to a particular place, and that place has a time zone associated with it (but the time zone might change for political reasons in the future,for example with daylight savings). If the venue changes, only the time zone data needs to be updated. An example would be an appointment in London this coming October 12th at 10:30.
*Floating Time*
Floating (or local) time is always relative to the time zone of the observer. If you travel and change time zones, floating time changes zones with you. If you and another observer are in different time zones and observe the same floating time value, the absolute times you calculate will be different. An example would be your 8:00 morning workout.
*When to Use Each Kind*
Use whichever kind of time most succinctly and completely handles your time needs. Don't depend on time zone information as a proxy for a location; that's depending on a side effect, which is always brittle. Always store location information separately if it's important.
Examples:
Recording an event: Absolute
Log entries: Absolute
An appointment: Fixed
Your daily schedule: Floating
Deadlines: Usually fixed time, but possibly absolute time.
> I feel the standard interchange format for datetimes really should be 64 bit Unix timestamps.
Several people have already replied pointing out that for scheduling events in the future, particularly recurring events, it's practically necessary to refer to time zones.
So I'll just mention the problem of leap seconds, which are announced six months in advance. If a one-second error could cause problems then probably you should use TAI rather than UTC. But you still need UTC for other purposes, so probably you need both and so you need to keep track of whether a particular timestamp is TAI or UTC.
And then your application has to schedule a recurring weekly meeting happening at exactly 9:00 CST, and suddenly, you have to update your DB schema and all code instances everywhere to actually deal with the time zones. And then you realize you'd be better off if you were just using a sane time zone library from the start instead of pretending time zones don't exist.
Besides the "meeting time" exception others have mentioned, you should be aware of timezones when grouping records into days/weeks/months/years/etc. The timezone affects where you "cut" the continuum into groups. Does Joe's sale count toward his January quota or February? This has all kinds of interesting questions: do you use the user's time zone? The local office timezone? The HQ timezone? UTC for everything? What if the user moves? Stack Overflow's "fanatic" badge just uses UTC: https://stackoverflow.com/help/badges/83/fanatic
Use UTC everywhere, then display in the user's timezone is a perfectly valid pattern...for specific use cases. Those use cases are very common, but many people over generalize, and assume that it can handle all cases.
'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.
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!
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 is that one of the top feature requests is to display short timezone codes.
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), 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.
> 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.
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.
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.
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
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.
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.
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).
> Let's take take a look, using the disastrously bad unix libc timezone tools
Are there any more examples of them causing issues to warrant being called "disastrously bad"? This post just seems to have one example of bad error handling when they the TZ env var is set incorrectly.
I'm genuinely interested if they actually are bad since they are used a lot.
They usually work because people check and notice mistakes.
It gets worse now that you have countries next to each other that are out of sync on daylight saving - America/Los Angeles doesn’t work for those south of the border anymore - but you won’t notice except two weeks a year.
Strangely I’ve noticed some systems give you WAY more cities than in the standard library - and I’m not sure why. Linode had way more options than just America/Chicago but didn’t have St Paul.
And trying to schedule things in advance across the daylight saving time difference is even more confusing.
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 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.
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.
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.
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?
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.
> The mktime() function converts a broken-down time structure, expressed as local time, to calendar time representation. The function ignores the values supplied by the caller in the tm_wday and tm_yday fields. The value specified in the tm_isdst field informs mktime() whether or not daylight saving time (DST) is in effect for the time supplied in the tm structure: a positive value means DST is in effect; zero means that DST is not in effect; and a negative value means that mktime() should (use timezone information and system databases to) attempt to determine whether DST is in effect at the specified time.
So, not specified.
POSIX is no clearer about which choice it will make [1]:
> The mktime() function shall convert the broken-down time, expressed as local time, in the structure pointed to by timeptr, into a time since the Epoch value with the same encoding as that of the values returned by time(). The original values of the tm_wday and tm_yday components of the structure shall be ignored, and the original values of the other components shall not be restricted to the ranges described in <time.h>.
> A positive or 0 value for tm_isdst shall cause mktime() to presume initially that Daylight Savings Time, respectively, is or is not in effect for the specified time. A negative value for tm_isdst shall cause mktime() to attempt to determine whether Daylight Savings Time is in effect for the specified time.
> Local timezone information shall be set as though mktime() called tzset().
> The relationship between the tm structure (defined in the <time.h> header) and the time in seconds since the Epoch is that the result shall be as specified in the expression given in the definition of seconds since the Epoch (see XBD Seconds Since the Epoch) corrected for timezone and any seasonal time adjustments, where the names other than tm_yday in the structure and in the expression correspond, and the tm_yday value used in the expression is the day of the year from 0 to 365 inclusive, calculated from the other tm structure members specified in <time.h> (excluding tm_wday).
> Upon successful completion, the values of the tm_wday and tm_yday components of the structure shall be set appropriately, and the other components shall be set to represent the specified time since the Epoch, but with their values forced to the ranges indicated in the <time.h> entry; the final value of tm_mday shall not be set until tm_mon and tm_year are determined.
... but i think the final paragraph implies that the tm_isdst field in the input time should at least be set to indicate which choice was made!
Java is explicit [2]:
> In most cases, there is only one valid offset for a local date-time. In the case of an overlap, where clocks are set back, there are two valid offsets. This method uses the earlier offset typically corresponding to "summer".
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.)
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.
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?
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.
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) 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.
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.
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.
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 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.
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.
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.
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 :)
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.
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.
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!
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.
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.
It's absolutely right to criticize insane behavior even if said behavior is documented. LOL "helpfully" being substituted to the output is absolutely insane.
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"!
Let's pick apart that documentation and the actual behavior, shall we?
By the documentation "EST", "EDT" and "America/Los_Angeles" are not valid TZ environment variable values, as none of them matches any of the formats. offset doesn't seem to be optional, and within offset hours are not optional.
Ok, maybe it is too pedantic, a permissive implementation can interpret no offset as 0, right? But that's not what happens here. The implementation looks up the timezone by the provided name somewhere, and only when it doesn't find it it falls back to 0 as an offset.
This lookup behavior doesn't seem to be documented on that page. It's not described in the GNU date man page either even though it uses TZ='America/Los_Angeles' as an example.
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.
jwalton|5 years ago
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.
Lvl999Noob|5 years ago
kelnos|5 years ago
But agree that this is just a grab bag of confusing garbage.
[0] I suppose if CA does away with DST (or keeps it permanently), I will have to change...
kenniskrag|5 years ago
Europeans turn back clocks for daylight saving, perhaps for last time. source: https://www.dw.com/en/europeans-turn-back-clocks-for-dayligh...
phlo|5 years ago
EST is always UTC-4 and EDT is always UTC-5. Both of these exist throughout the year. The only change happening in Spring/Autumn is that some places change which time zone they currently observe.
This also addresses the second problem that you outlined. As long as the query is properly specified (if you want information related to a location, use America/New York; if you want information related to a time zone, use the time zone), you can always get an unambiguous and correct answer.
jmgao|5 years ago
Individual states are toying with the idea as well [1], which presents a problem if one of the tzdata locations decides to change its rules. You're screwed no matter what you choose to do. :-(
1: https://www.syracuse.com/state/2020/11/state-senator-introdu...
kenneth|5 years ago
bob1029|5 years ago
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.
detaro|5 years ago
rbanffy|5 years ago
No.
If a human says a recurring meeting happens at 9 AM Pacific time and the following week they are in daylight saving time, it'll still happen at 9 AM local time. Preserving intent is crucial in this case.
kstenerud|5 years ago
Time is something that developers get wrong more often than any other type. Your time data requirements change as your use case for the time changes.
From https://github.com/kstenerud/compact-time/blob/master/compac...
Aside from issues of synchronization, leap seconds, data container limitations and such, it's important to choose the correct kind of time to store, and the right kind depends on what the purpose of recording the time is.
There are three main kinds of time:
*Absolute Time*
Absolute time is a time that is fixed relative to UTC (or relative to an offset from UTC). It is not affected by daylight savings time, nor will it ever change if an area's time zone changes for political reasons. Absolute time is best recorded in the UTC time zone, and is mostly useful for events in the past (because the time zone is now fixed at the time of the event, so it probably no longer matters what specific time zone was in effect).
*Fixed Time*
Fixed time is a time that is fixed to a particular place, and that place has a time zone associated with it (but the time zone might change for political reasons in the future,for example with daylight savings). If the venue changes, only the time zone data needs to be updated. An example would be an appointment in London this coming October 12th at 10:30.
*Floating Time*
Floating (or local) time is always relative to the time zone of the observer. If you travel and change time zones, floating time changes zones with you. If you and another observer are in different time zones and observe the same floating time value, the absolute times you calculate will be different. An example would be your 8:00 morning workout.
*When to Use Each Kind*
Use whichever kind of time most succinctly and completely handles your time needs. Don't depend on time zone information as a proxy for a location; that's depending on a side effect, which is always brittle. Always store location information separately if it's important.
Examples:
Recording an event: Absolute
Log entries: Absolute
An appointment: Fixed
Your daily schedule: Floating
Deadlines: Usually fixed time, but possibly absolute time.
bloak|5 years ago
Several people have already replied pointing out that for scheduling events in the future, particularly recurring events, it's practically necessary to refer to time zones.
So I'll just mention the problem of leap seconds, which are announced six months in advance. If a one-second error could cause problems then probably you should use TAI rather than UTC. But you still need UTC for other purposes, so probably you need both and so you need to keep track of whether a particular timestamp is TAI or UTC.
levosmetalo|5 years ago
zokier|5 years ago
UNIX timestamps are ambiguous.
ISO 8601 is perfectly good interchange format.
pjungwir|5 years ago
Besides the "meeting time" exception others have mentioned, you should be aware of timezones when grouping records into days/weeks/months/years/etc. The timezone affects where you "cut" the continuum into groups. Does Joe's sale count toward his January quota or February? This has all kinds of interesting questions: do you use the user's time zone? The local office timezone? The HQ timezone? UTC for everything? What if the user moves? Stack Overflow's "fanatic" badge just uses UTC: https://stackoverflow.com/help/badges/83/fanatic
hyperpape|5 years ago
Use UTC everywhere, then display in the user's timezone is a perfectly valid pattern...for specific use cases. Those use cases are very common, but many people over generalize, and assume that it can handle all cases.
netsharc|5 years ago
juddgaddie|5 years ago
All you need to read/remember is this, this applies everywhere not just with date.
arminiusreturns|5 years ago
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!
jonathanberger|5 years ago
One of the first surprising things you learn after launching a timezone conversion website https://news.ycombinator.com/item?id=1133613 is that one of the top feature requests is to display short timezone codes.
c0l0|5 years ago
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), 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|5 years ago
sschueller|5 years ago
[1] https://en.wikipedia.org/wiki/Swatch_Internet_Time
throwaway2245|5 years ago
joquarky|5 years ago
sdm|5 years ago
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.
soco|5 years ago
messe|5 years ago
javbit|5 years ago
ycombobreaker|5 years ago
tal8d|5 years ago
xyst|5 years ago
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|5 years ago
larrik|5 years ago
I bet storing an offset is far more pain, given that anyone in a DST area will have 2 offsets per year.
shadowgovt|5 years ago
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|5 years ago
cfstras|5 years ago
The BSD version of date shipped with MacOS 10.15 also does not seem to have this bug.
prussian|5 years ago
de_Selby|5 years ago
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|5 years ago
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.
grenoire|5 years ago
NovemberWhiskey|5 years ago
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|5 years ago
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.
Tepix|5 years ago
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|5 years ago
Unfortunately, .beat time didn’t catch on.
andruby|5 years ago
k_sze|5 years ago
Ayesh|5 years ago
twic|5 years ago
> The mktime() function converts a broken-down time structure, expressed as local time, to calendar time representation. The function ignores the values supplied by the caller in the tm_wday and tm_yday fields. The value specified in the tm_isdst field informs mktime() whether or not daylight saving time (DST) is in effect for the time supplied in the tm structure: a positive value means DST is in effect; zero means that DST is not in effect; and a negative value means that mktime() should (use timezone information and system databases to) attempt to determine whether DST is in effect at the specified time.
So, not specified.
POSIX is no clearer about which choice it will make [1]:
> The mktime() function shall convert the broken-down time, expressed as local time, in the structure pointed to by timeptr, into a time since the Epoch value with the same encoding as that of the values returned by time(). The original values of the tm_wday and tm_yday components of the structure shall be ignored, and the original values of the other components shall not be restricted to the ranges described in <time.h>.
> A positive or 0 value for tm_isdst shall cause mktime() to presume initially that Daylight Savings Time, respectively, is or is not in effect for the specified time. A negative value for tm_isdst shall cause mktime() to attempt to determine whether Daylight Savings Time is in effect for the specified time.
> Local timezone information shall be set as though mktime() called tzset().
> The relationship between the tm structure (defined in the <time.h> header) and the time in seconds since the Epoch is that the result shall be as specified in the expression given in the definition of seconds since the Epoch (see XBD Seconds Since the Epoch) corrected for timezone and any seasonal time adjustments, where the names other than tm_yday in the structure and in the expression correspond, and the tm_yday value used in the expression is the day of the year from 0 to 365 inclusive, calculated from the other tm structure members specified in <time.h> (excluding tm_wday).
> Upon successful completion, the values of the tm_wday and tm_yday components of the structure shall be set appropriately, and the other components shall be set to represent the specified time since the Epoch, but with their values forced to the ranges indicated in the <time.h> entry; the final value of tm_mday shall not be set until tm_mon and tm_year are determined.
... but i think the final paragraph implies that the tm_isdst field in the input time should at least be set to indicate which choice was made!
Java is explicit [2]:
> In most cases, there is only one valid offset for a local date-time. In the case of an overlap, where clocks are set back, there are two valid offsets. This method uses the earlier offset typically corresponding to "summer".
[1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/m...
[2] https://docs.oracle.com/en/java/javase/11/docs/api/java.base...
bolle|5 years ago
apaprocki|5 years ago
dan-robertson|5 years ago
deepsun|5 years ago
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|5 years ago
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:Ar...
shadowgovt|5 years ago
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) is a great solution to this problem for most use cases... But you need to keep your copy of it updated, because laws change.
eyelidlessness|5 years ago
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.
FabHK|5 years ago
jacobsenscott|5 years ago
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|5 years ago
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.
a5withtrrs|5 years ago
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.
Floegipoky|5 years ago
davidgtl|5 years ago
ggm|5 years ago
Well.. Brisbane is not Sydney time. half the year we're 1 hour offset. AEST is not AEDT.
ZainRiz|5 years ago
And even Central Standard Time is ambiguous
https://www.zainrizvi.io/blog/falsehoods-programmers-believe...
nelsonenzo|5 years ago
Nice blog post.
qwertox|5 years ago
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|5 years ago
todd8|5 years ago
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|5 years ago
kanzenryu2|5 years ago
rini17|5 years ago
tacostakohashi|5 years ago
NoOneNew|5 years ago
prussian|5 years ago
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.
unknown|5 years ago
[deleted]
phoronixrly|5 years ago
It seems to me that the author did not initially read the documentation they linked to (https://www.gnu.org/software/libc/manual/html_node/TZ-Variab...) and is now complaining in an annoying and entitled manner.
steerablesafe|5 years ago
biggerfisch|5 years ago
In this specific case though, even those docs do not explain what happens if the value is "invalid"!
steerablesafe|5 years ago
By the documentation "EST", "EDT" and "America/Los_Angeles" are not valid TZ environment variable values, as none of them matches any of the formats. offset doesn't seem to be optional, and within offset hours are not optional.
Ok, maybe it is too pedantic, a permissive implementation can interpret no offset as 0, right? But that's not what happens here. The implementation looks up the timezone by the provided name somewhere, and only when it doesn't find it it falls back to 0 as an offset.
This lookup behavior doesn't seem to be documented on that page. It's not described in the GNU date man page either even though it uses TZ='America/Los_Angeles' as an example.
rbanffy|5 years ago
protomyth|5 years ago
prussian|5 years ago
Annatar|5 years ago
It's not "EST", it's EST5EDT because the string "EST" shows up in other time zone designations. Learn time zones, then come back.
unknown|5 years ago
[deleted]
ehwhyreally|5 years ago
yboris|5 years ago
https://www.youtube.com/watch?v=-5wpm-gesOY
7OVO7|5 years ago