Timezone Bullshit(blog.wesleyac.com) |
Timezone Bullshit(blog.wesleyac.com) |
And even Central Standard Time is ambiguous
https://www.zainrizvi.io/blog/falsehoods-programmers-believe...
Nice blog post.
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.
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!
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
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 seems to me that the author did not initially read the documentation they linked to (https://www.gnu.org/software/libc/manual/html_node/TZ-Variab...) and is now complaining in an annoying and entitled manner.
It's not "EST", it's EST5EDT because the string "EST" shows up in other time zone designations. Learn time zones, then come back.
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.
In this specific case though, even those docs do not explain what happens if the value is "invalid"!
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.
If the file specification filespec is omitted, or its value cannot be interpreted, then Coordi‐
nated Universal Time (UTC) is used. If filespec is given, it specifies another tzfile(5)-format
file to read the timezone information from. If filespec does not begin with a '/', the file
specification is relative to the system timezone directory. If the colon is omitted each of the
above TZ formats will be tried.So even if someone finds this sentence somehow this is still underspecified. The full logic seems to be for a TZ that doesn't start with ':' :
1. First format tried, if it fails...
2. ...interpret TZ as filespec, if it fails...
3. ...interpret TZ as std with offset 0.
Note that there is fallback parsing of TZ that is not described at all (essentially 3rd and 4th formats), and two fallbacks, not one.
TZ database includes "America/Santiago" and "America/Sao_Paulo" so clearly it means the continent and not just the US.
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?
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.
If `TZ=EST date` adjusts the offset to EST, then a reasonable person would expect `TZ=EDT date` to either adjust the offset to EDT, or fail noisily if it's not aware of that offset code.
At a skim through the documentation I don't see anything warning about it's current behaviour.
But it is aware of it! You just told it, using the TZ variable, what EDT is. It's a timezone called EDT, with no offset from UTC!
If you wanted an offset, you should have written `TZ=EDT+4 date`
> But it is aware of it! You just told it
The user didn't intend to. Defining a new offset code should be explicit, not a silent fall-back when it's unable to find EDT.
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.
If you set your machine to something weird, then expect the utility that reports on those settings to report the weird settings you set.
But you can still define a brand new timezone with the TZ variable. Perhaps you want to argue that you shouldn't be able to, but that's what it's for, as the document linked above clearly states.
Well, they should have read the docs. They clearly show examples of how to define a timezone right there. It isn't a fallback, it's what TZ is for.
Edit: perhaps `date` should have a `-z --zoneinfo` option, in which you could specify a timezone by file and it would fail if the file did not exist. This would fix the issue and avoid breaking existing scripts.
You can say that about any bad design choice, and in this case I'd argue that the linked docs don't even agree with the behaviour. The syntax given by the docs for creating a new timezone requires explicitly specifying an offset (then optional stuff like daylight savings).
The quirk may be documented elsewhere, but before getting caught out by it the average user has no reason to be searching through multiple sources of documentation for an oddity they don't yet know exists.
> It isn't a fallback, it's what TZ is for.
If I'm understanding, `TZ=EDT` will search for an "EDT" timezone in its database, fail, then instead silently default to creating a new timezone with 0:00 offset. That's pretty much how I'd define a fall-back.
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.
So at/near the equator, in a place like Panama, you will get roughly 12 hours of daylight in both the December and June Solstices.
* https://www.timeanddate.com/sun/panama/panama
Whereas in the Edinburgh you go from having 7 hours of daylight in December to over 17 hours in June:
* https://www.timeanddate.com/sun/uk/edinburgh
So people want those 7 hours to be when it's most convenient for them.
The basic idea is that it's easier to convince everyone that is actually 5:00pm and time to leave work than it is to convince just your boss that you want to start work an hour earlier and leave and hour earlier.
This problem is then applied to politicians and other powerful people, who want to go golfing after work. If there's no DST, the sun will set "earlier" according to the clock, and you can't get in a full 18 holes.
So therefore, we change all the clocks so that powerful rich people can go golfing.
No other group of people sees any benefits to DST.
It aims to shift the usable daylight hours to correspond with human activity.
If you search HN you’ll find plenty on this topic.
India does not use timezones. Every business, school, office who has business hours, use something like Winter Timings Summer Timings. Schools & such use 14 Oct to 14 Apr as Winter, & other 6 months as summer. My school used to open at 6 in summers, & 7:30 or 8 in winters.
Here in US they keep the opening timings same throughout the year, but go through this DST shenanigans.
There's no possible way businesses are going to adjust their hours twice yearly to let employees get more sunshine, but DST does that effectively by ensuring official timekeeping gets moved about on them.
Yes, but you can better align the available light with things like commutes and school hours - so that people commute in light instead of the dark, for example.
However, I recall that farmers are very split on the issue when polled - it impacts on their work shifts as well.
Power. The sensation of raw power.
By and large, the best way to eliminate DST would be for one or more sufficiently powerful lawmakers or political executives to say: this is no longer benefiting the public at large, and we are going to stop!
These are the folks empowered to change the date on which DST transitions (at least stateside). These are also the same folks whose careers have been mostly defined by the deliberate and incremental accumulation of power into their own hands.
If you're wired for that kind of desire for power, the ability to tell the entire country: okay, I am changing time! It happens on this date! --must be simply _irresistible_. I mean: you're literally changing TIME. Hot shit! The entire population has to respond! You're changing TIME! Why give that up?
While I'm storytelling and presuming, I'll note that this needn't be a deliberate, conscious decision; I'm only suggesting that the people positioned to change this sort of thing are probably naturally wired to resist doing so, and may not even be aware of why themselves.
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...
https://stackoverflow.com/questions/4309030/difference-betwe...
Europeans turn back clocks for daylight saving, perhaps for last time. source: https://www.dw.com/en/europeans-turn-back-clocks-for-dayligh...
The EU's "Ban DST" is the same populist bullshit as Trumps "inject Windex to cure COVID". Based on nothing and ignorant at best.
And the cherry on top is, if you ask the EU if they want to receive a no strings attached gift of €10.000.000.000.000 or €11.000.000.000.000, it would still take them 20 years to decide. No way they will ever reach consensus on DST.
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.
Except you have those reversed. :)
Unfortunately not. Australia also used EST until recently. Now they've introduced AEST, but I'm sure there's systems out there using EST.
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...
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.
All you need to read/remember is this, this applies everywhere not just with date.
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!
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.
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.
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.
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.
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.
I bet storing an offset is far more pain, given that anyone in a DST area will have 2 offsets per year.
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).
$ TZ=EDT gdate
Wed Feb 10 13:22:23 UTC 2021
$ gdate --version
date (GNU coreutils) 8.32
...
The BSD version of date shipped with MacOS 10.15 also does not seem to have this bug.
Testing with https://hub.docker.com/_/busybox, it seems like musl also has this problem. uclibc is not affected.
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.
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.
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.
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.
Unfortunately, .beat time didn’t catch on.
$ 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
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?
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...
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.
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.
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.
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.
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.
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.
Well.. Brisbane is not Sydney time. half the year we're 1 hour offset. AEST is not AEDT.
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.
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.
And fixed time I would call local time. Why call it fixed? Because it's tied to a location?
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.
You store your datetimes/instants as UTC, you store your "every day at 9 CST" rule separate from that.
Your rule table might have a column for a cron expression, and a column for the tz database name.
Meanwhile, your table for the meeting records has the time represented as a UTC timestamp.
UNIX timestamps are ambiguous.
ISO 8601 is perfectly good interchange format.
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.
I still don't understand the arguments about a future date requiring a timezone. UTC can 100% accurately represent a future date or event without any ambiguity. If a user, meeting or other aggregate has a culture/timezone preference, this is a completely separate business fact from the time.
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 .
Summary:
UT1 - noon is when the sun is above you, day has 86400 seconds (not SI seconds)
TAI - noon drifts away from when the sun is above you, day has 86400 SI seconds
UTC - noon is when the sun is above you (+/- 1 second), day has 86400+/-1 SI seconds
Difference UT1-TAI: continuously diverging
Difference UT1-UTC: continuously diverging up to less than +/-1 second, then discretely jumps back when it gets too big (leap seconds)
Difference TAI-UTC: increasing in discrete increments of +/-1 full second (leap seconds)
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.
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."
> 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...
Fact of the matter is, your preferences depend on where you live, your lifestyle, and the amount of time you spend on date&time fuckery in code. It's a contentious issue.
(This also raises the point that you need to preserve zone information, not just the UTC offset. Otherwise the meeting will move after a daylight saving time change, which is not usually what people want.)
So I went with floating vs fixed because it feels less prone to ambiguity. "Fixed" is fixed to a particular zone, and "floating" floats along with me as my current zone changes.
If the meeting is in _the other_ CST (the Taipei one), there's good news: Taipei doesn't do daylight savings. On the flip side, Chicago attendees might dial in fourteen hours early, so Asia/Taipei is a safer bet, too.
A future event at local time requires a location, because the timezone may yet change at that location. Suppose we meet Nov 1st 2017 in Istanbul and decide to repeat this the year after. We agree to meet again Nov 1st 2018 in Istanbul 10:00 local time. This meeting would have been projected to happen at UTC 8:00, because Turkey was scheduled to switch to UTC+2 on October 30 2018.
However, the government decided to not change the timezone and stay on UTC+3. So our meeting, being scheduled for 10:00 local time, would move from UTC 8:00 to UTC 7:00 at the stroke of a pen. If your software had recorded UTC time, it would be ignorant of this change and consequently it would show the meeting at 11:00 local time. You'd be one hour late.
This change in the tz DB is a little window into the questionable cultural achievement that is local time: https://github.com/eggert/tz/commit/e15ef79a603a2fba89ad8f38...
It's not that a future date requires a time zone, you are right that can be 100% represented with a fixed timestamp. But there is the extreme case that time zone rules may change from the time you schedule the event to the time it happens, and in that case your event is now at the wrong time.
Consider the case where you have a weekly meeting at 9:00 AM on Tuesdays in an America/Chicago office. You could surely calculate the next N weeks of meetings and save them as UTC timestamps, taking into account that we shift into daylight savings time at some point, so you end up with a nice list of timestamps at 9:00 local time. But if the time zone rules change at any point (say, Chicago decides not to observe daylight savings time any more), now all of your meetings are an hour off.
If you had saved the meetings in a more verbose but true-to-intent format that properly captures "Every Tuesday at 9:00 AM America/Chicago", then at the time those rules changed you would either automatically have updated meeting timestamps, or some consolidation process could go and update the meeting times.
Even without sweeping changes like that, we still have unscheduled leap seconds, minutes, etc. every once in a while, which will also mess up your timestamps. I'm actually excited to see the day my calendar somehow ends up with a meeting at exactly 9:00:01.
Also discussed on HN back in the days: https://news.ycombinator.com/item?id=19500640
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.
It doesn't solve every conceivable timezone issue, but it solves 99% of the problems most developers would have with it.
The folks who study this:
* https://en.wikipedia.org/wiki/Chronobiology
Seem to have come to a consensus that if we're going to get rid of DST, then health-wise it is best to have Standard Time year-round:
> As an international organization of scientists dedicated to studying circadian and other biological rhythms, the Society for Research on Biological Rhythms (SRBR) engaged experts in the field to write a Position Paper on the consequences of choosing to live on DST or Standard Time (ST). The authors take the position that, based on comparisons of large populations living in DST or ST or on western versus eastern edges of time zones, the advantages of permanent ST outweigh switching to DST annually or permanently.
* https://journals.sagepub.com/doi/full/10.1177/07487304198541...
For a longer-read, referencing quite a bit of academic literature, but a conclusionary snippet:
> In summary, the scientific literature strongly argues against the switching between DST and Standard Time and even more so against adopting DST permanently. The latter would exaggerate all the effects described above /beyond/ the simple extension of DST from approximately 8 months/year to 12 months/year (depending on country) since /body clocks/ are generally even later during winter than during the long photoperiods of summer (with DST) (Kantermann et al., 2007; Hadlow et al., 2014, 2018; Hashizaki et al., 2018). Perennial DST increases SJL prevalence even more, as described above.
* https://www.frontiersin.org/articles/10.3389/fphys.2019.0094...
Other position papers that I've dug up over the years when curiosity got the better of me:
> Society for Research on Biological Rhythms (SRBR) is dedicated to advancing rigorous, peer-reviewed science and evidence-based policies related to sleep and circadian biology.
* https://srbr.org/advocacy/daylight-saving-time-presskit/
* (refs, with pro and con): https://srbr.org/wp-content/uploads/2020/09/DST-References-S...
European Sleep Research Society:
* https://esrs.eu/wp-content/uploads/2019/03/To_the_EU_Commiss...
Canadian Society for Chronobiology:
* https://www.theglobeandmail.com/opinion/article-turn-back-th...
* https://twitter.com/ChronobioCanada/status/11906320965969264...
American Academy of Sleep Medicine (with 36 footnotes if you want to dig further):
* https://jcsm.aasm.org/doi/10.5664/jcsm.8780
* https://doi.org/10.5664/jcsm.8780
The Centre for Chronobiology, based at the Psychiatric University Hospital (University of Basel):
* http://www.chronobiology.ch/wp-content/uploads/2019/08/JBR-D...
(Personally, I'm just going to trust the experts on this as I don't have the energy to go digging in things. A quick cursory Google/DDG search is enough for me.)
Well the majority of people, countries, and square-kilometres of land doesn't have daylight saving so you'll have to do better than that.
At some latitudes with some social norms (regarding things like school start times) DST is beneficial. In others it's not. There are no absolutes here.
[Ed. Nevermind, sorry, I see you're referring to a future point. My bad. You're right.]
For stamping times like in a log though UTC should always be used server side.
Also, I would argue time manipulation is full of many "edge cases" like this one, which is why it's so hard. It's going to work fine until it doesn't.
Having the length of a second always be the same is kind of important.
All the calendaring tools I use or am aware of, at this point, keep up with time zone correctly (or have so far). I set the meeting for, say, 10 CST, and it's clear to my colleagues in Seattle that it will be 8 for them, just as it's clear for my coworkers in DC that it'll be 11.
What if you schedule a meeting in a year's time in a timezone that doesn't have Daylight Savings Time but that government decides to add it and now the meeting is at a time that doesn't exist?
But your use case it also talking about when using a tool that is specifically designed to deal with this issue. What about when you are trying to find a good time (AFAIK most calendars don't have good tooling for collaboratively choosing a meeting time). If you do this in your favourite chat app then you probably have no timezone support. (This would be an awesome feature though)
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.
That's not accurate.
>This online consultation, which ran from 4 July to 16 August 2018, received 4.6 million responses from all 28 Member States, the highest number of responses ever received in any Commission public consultation. According to the preliminary results (see annex), 84% of respondents are in favour of putting an end to the bi-annual clock change.
It's worse than just EU/UK offset. You would have Northern Ireland and the Republic of Ireland in different timezones.
The consultation had 4.6 million responses.
> Having variable time offsets between EU and UK would add yet another layer of disruption on top of Brexit.
So?
That's definitely not accurate.
> The EU decided to chicken out and let the members decide for themselves
There are reasons the EU doesn't just enforce timeZones across its members.. So this is a 'strange' comment that bothered me.
At least all the institutions got it right, so it was enough to announce "Windows|Red Hat|iOS|Android|whatever is wrong today, ignore it and use some other clock".
* https://www.timeanddate.com/sun/singapore/singapore
DST is mostly for countries closer to the poles. See my other comment:
I guess it needs to be a 4-dimensional coordinate, where 1 axis can slide around...
If a foreign army invades Belgium and changes its timezone, Europe/Brussels will get updated.
A disproportionate amount of which were from Germany (2/3 of the responses, even though Germany only is only ~ 16 % of the EU-population pre-Brexit).
Your calendar can store the GMT time for lookups but it will need to recalculate this if the timezone data changes.
Furthermore it isn't as simple as "storing GMT" for repeating events. As the offset will be different for different occurrences. So you need to store the original timezone for the recurrence rule. (And see the above problem about the absolute time of a current local time being unknowable)
Yes, you do need to store the location of the scheduler so that you can adjust everything as appropriate, and of course you need to schedule the time the event was created. But you still only store those times in GMT.
By the way, what I’m describing is the way every AWS system does it.
Edit : Oddly, I can’t reply to your reply to this, but I already addressed the case you were talking about in this comment.
If I schedule an event in 1 year at 08:00 in MyCityTimezone and you store that the event occurs at 13:00 GMT then 3 months later MyCity decides that they aren't doing Daylight Savings Anymore your GMT time is now wrong. My event must still occur at 08:00 which is now 14:00 (or whatever) GMT.
"Just" storing it in GMT isn't enough. You probably do want to do that but you need to store the local time as well and update GMT to match if timezones change.
This is very frequently done wrong because timezones don't change often so the "Just store GMT" mostly works. But if you are writing a high quality system you need to deal with these cases.
It reminds me of when I'm camping. I usually fall into a dawn-based time system: Wake up around ~dawn, eat breakfast ~d+2h, lunch ~d+6h, dinner ~d+12h, bed down ~d+16h. You maximize daylight this way but the main problem is that you end up drifting relative to everyone else and if you want to rely on a standard watch to keep your schedule it requires some mental math.
I'd love to figure out how to use a combination of dawn-based time system for my daily routines plus UTC for remote collaboration.
When towns had public mechanical clocks they were typically frequently adjusted (even daily) so that noon was when the sun was directly overhead.
Once railroads were developed their schedules were a mess since each time had to be in the time of the specific station. So the railroads got time zones introduced.
Then when the move for DST came around it had to be something easy to calculate, thus a one hour shift. Sort of like the Dow Jones: something that could be easily calculated by hand.
but by using DST we are just pretending that we didn't ask people/companies to adjust their schedules. in reality they did, just the "clock" stayed the same.
Edit: If changing schedule is normalized, then it would be just as convenient as changing the clock. In countries without DST, if someone started using DST instead of changing their own schedule, it would be just as difficult.
The primary benefit of mass schedule change is that it might make (some) programmers' lives easier. The disadvantage is that it makes everyone else's lives harder as they adapt to schedule shifts.
(Clocks exist to serve people, people don't exist to serve clocks.)
Then again, this would be an issue for road workers (those who repair highways or other roads) and maybe trash collection services. So it begins... Horrible.
A perfectly human solution really: work around the shift in daylight hours across the year by fiddling with the clocks. The whole thing with schedules and timetables is a self inflicted problem in a post-industrial society, sure, but workarounds are never really meant to be more than a bandaid.
In theory. Going by the normal justification for daylight savings, the convenient hours to have sun are the afternoon. But if that was it, then you'd expect the clock to be pushed even further in the winter.
* https://en.wikipedia.org/wiki/Time_in_Europe
France should probably, AFAICT, be in WET (like the UK) and Spain definitely should be. Solar time offsets are quite off for them:
* http://blog.poormansmath.net/how-much-is-time-wrong-around-t...
* https://github.com/stefano-maggiolo/solar-time-vs-standard-t...
The only real downside I see is that if the day number changes during your "day" it could be confusing. However I think we will quickly learn to deal with it (overnight shifts have been a thing forever and doctors seem to manage). Plus we already have a weaker form of this when we are talking about late-night activities so I think we will figure it out.
Humans have circadian rhythms that have health effects:
* https://en.wikipedia.org/wiki/Chronobiology
See my comment linking to various position papers of the scientists who study in this field:
* https://news.ycombinator.com/item?id=26088541
They generally want to get rid of DST completely and stick with Standard ("winter") Time all year round. (I don't know enough to gainsay them.)
But what about the 99% rest of population? It's a mistake thinking that because they dont realllly care they will accept either way.
Resistance to change is huge, especially when it plays into the narrative "Bruxelles demanded it"
And what I meant by lack of popular consultation is that if you go on EU streets and ask about this change 95% of people will have no idea what you are talking about.
And a disproportionate proportion of those (more than two thirds) were from Germany, were that topic was an especially hot issue for some reason or other.
I was just pointing out that it's wrong to say this this decision had ample consultation, because overwhelmingly the population is not aware of it.
So in Toronto I can wake up at 12:00 and in London people can wake up at 8:00. It just changes the number on the clock.
>No other group of people sees any benefits to DST.
Ah yes, because only powerful rich people would benefit from extra time in the evening to do outdoor activities.
But truthfully, if our society wants more time in daylight after work... let's just leave work earlier. I mean, we are doing that, we're just changing the clocks and pretending we aren't. It's dumb.
It probably depends somewhat on latitude and longitude, I for one would prefer year round daylight saving time as I like the extra evening light in the summer and it’s dark when my kids leave for school in the winter anyway. I don’t golf.
The idea of shifting working hours to account for the season changes might work in some contexts but not others. Sure, if I’m an office “information worker” it’s probably not a big deal to shift to 7-4 in the summer. But I don’t think that’s going to work for retail, grocery, post office, restaurants, gyms, pharmacies, etc. where the public isn’t going want to constantly adjust to and guess at changing opening and closing times.
We just all change the clocks as well and pretend that we didn't. And it's stupid.
My point is not for or against daylight saving time, just that shifting work hours is not a viable alternative to it. And if we do get rid of changing clocks, there’s a decent chunk of the population that has expressed a preference for permanent daylight saving time rather than standard time.
It’s worth nothing that in Russia they experimented with permanent daylight time some years ago, and at first it was highly supported. However, after some years support for it dropped and they moved to permanent standard time. However, Russia deals with some unique geographical scenarios such as cities with extreme northern latitudes.
Do state have the option to change their timezone altogether?
Permanent DST is the same as shifting one tz over and not having DST and this would make more sense.
Huh? I'll flip the question around on you: What places are there that don't observe DST that do change working hours seasonally, especially in a coordinated way? I haven't heard of any.
Yes, literally every state/province in North America that doesn't observe DST. I don't know what goes on in Europe, but nobody in Arizona for example changes the open/close time of their barbershop, restaurant, or gas station solely due to the time the sun rises...
Farmers need to work on daylight. They can't change their schedule when the clocks change. So during half the year, the busy half, all the business start closing down an hour early.
It's like DST is the wrong solution to an XY problem.
Thinking practically though, DST is bound to work without enforcement, so it has that advantage.
What with covid/wfh, I have been wondering is this might be the push needed to end DST. Because I sure as hell have changed the time I work. Dog walk in the dark in December because about 4 hours of daylight in Seattle? Fuck that, we walk the dogs smack in the middle of the day now, we can work when it's dark. Strap on the reflective gear, headlamp, and go for a run? Oh, hell no. 2 in the afternoon, baby; I'll fix that bug late afternoon.
I still get up super early, but instead of getting in that run before work, I just work. Then shift that running time to when the sun's up. But I speak from the position of the privileged tech worker (and one w/o a lot of meetings). There are still the DST issues of when children stand waiting for the school bus, et. al.
I think the main pain point would be customers being confused as to when companies are open.
This doesn't even work well with smartphones; all the calendar apps are hopelessly manual and can't answer something like "what are good times to run an errand involving steps X, Y, Z."
At best, you can ask it when people are available for a meeting and it will show you that everyone important is booked solid.
But why would so many people rely on a 1 hour difference that this would become a "main pain point"? I don't know the working hours of most places I go to. When I really want to know, I check Google Maps (or their website). Even then, when it's close to opening or closing hours by like an hour, I sometimes prefer not to trust it if it'd be too problematic for it to be closed after making the trip, because it does happen at times that it's incorrect. Small shops might not even follow their own stamped-on-the-window working hours strictly either.
Clocks in western China are four hours out of sync with their neighbors just over the southern border in Pakistan, for example. So do businesses in western China open from 1pm to 9pm? Do people eat breakfast at noon?
I'm really curious about that experience.
For example, people are used to banks always being open 9am to 5pm. With the approach you mentioned, it means that twice a year they will have to shift it. It means you will also have to shift your entire schedule, and calendar, and literally everything. Now think about some shops and places that will NOT be switching it and decide to keep the same hours. Then add-in the fact that some shops already change their hours even with the current system. For example, I have a daily recurring alarm for 7am. Under this proposed system, I will have to manually change it twice a year (while now it is done automatically due to the entire timezone switching twice a year).
You will simply get a logistical nightmare, since changing the entire clock is much much simpler than shifting each individual little scheduled item in your life.
Tl;dr: while i agree that logically your approach of shifting individual scheduling items to align with the daylight hours makes more logical sense, it makes more practical sense to just switch timezones twice a year for that purpose.
At least with respect to updating the alarm, that "logistical nightmare" can't be any worse than what we had before clocks updated themselves. I still remember having to update all clocks manually twice a year. It wasn't a big deal. Someone coming in late or missing an appointment because they forgot to update a clock happened rarely. Maybe it's not the case now, but you used to get multiple warnings reminding you to update your clocks.
> For example, people are used to banks always being open 9am to 5pm. With the approach you mentioned, it means that twice a year they will have to shift it. It means you will also have to shift your entire schedule, and calendar, and literally everything.
With respect to opening and closing hours of banks and shops, for those few people that go near opening or closing hours even in that time of the year, they'll make the mistake that day and either come back later when it's open or otherwise fix their issue that day or at least they won't make the same mistake the next day. The world wouldn't go up in flames because of this.
Iran used to do that. But for some reason they abandoned it and now use "normal" daylight saving time.
But it fails miserably at it.. Here in NYS all winter long it gets dark at 5PM. Summer, 9PM.
It's useless and just causes inevitable confusion every year.
The summer 9pm is the advantage of daylight savings. You get the sun up for 15 hours a day! Norther summer is great. Without daylight savings time, you’d get dark at 8pm in the summer and have an hour of “wasted” daylight before you got up. The “savings” part is to take the wasted light while you are sleeping and move it to the evening when you can enjoy it.
It does cause confusion though, and having implemented daylight savings code there are a bewildering number of rules around the world, there are even places that have double daylight savings. They shift once, then shift again for a two hour offset.
I'm still not sure it is worth the confusion it causes but I do have a better understanding of why it exists now. Thank you!
You either do DST or you mostly just pick a timezone and stick with it year round.
But a couple of kids got hit by buses in the morning, and there went that experiment:
https://www.mercurynews.com/2016/10/30/the-year-daylight-sav...
Edit: got the year wrong!
The reality is that if you don't do daylight savings, you're not going to have a collective switch in schedules and you're going to have to deal with what, for most, is sub-optimal sunlight.
Personally, I don't care much now because I mostly set my own schedule. But I'd have hated eliminating daylight savings when I was on a more fixed schedule.
I don't think anyone other than programmers thinks DST is not a huge pain in the ass.
Twice a year your bodyclock gets screwed up and you risk getting to work at the wrong time; once a year you even get a shorter night of sleep.
In Europe (hardly "programmer's country"), it took very simple polling to discover that DST was hugely unpopular. The population at large simply does not benefit, it was introduced for the good of industry and we're largely leaving behind that world. Good riddance.
Then the results were published and a few people were pissed off for not having been informed.
OTOH, it would have had been a discussion for 20 years otherwise.
I am happy we just have one tole shift left (to move to summer time, yay for me because I am on the western edge of a timezone)
Everyone, and I mean everyone, I talk to about DST hates DST and wants it gone. It's definitely not just programmers who dislike it.
Without DST why would I need to ask my boss to start an hour earlier? I've lived in places without DST and it was just fine, I didn't notice or miss any "extra" hour of daylight.
Changing your schedule works for you and your boss, but does not let people in other parts of the world know when they can reach you. Officially shifting something is necessary, and then you might as well have timezones.
In includes the most bizarre history:
> A century and a half ago, time zones didn’t exist. They were a consequence of the invention of railroads.
... and goes on to describe that it's suddenly so confusing and laughable that when it was 7:00 in New York, it would now be 8:00 in Chicago and 5:00 in San Francisco.
But what on Earth did the writer think the time was in San Francisco before there were time zones?
Before there were time zones, everyone synchronized to local noon. The result was much more fine-grained "time zones." What time zones did was to actually flatten those difference, leading to fewer time zones, because now suddenly the time in Maine was the same as the time in Michigan, despite being at completely different longitudes.
1. https://www.nytimes.com/2016/11/06/opinion/sunday/time-to-du...
That is true, but it did not bother anyone, because fast long-distance communication either did not exist or was very limited (e.g. smoke signals) and syncing of clocks wasn't necessary in everyday activities; for a medieval person, the idea that clocks in Vienna and Prague MUST be synchronized would be as strange as for us the idea that everyone in the same city should have their breakfast at the same time. It just did not serve any obvious purpose.
There are only two exceptions I can think of.
a) people doing astrological horoscopes for someone who was born in a different place (a big thing among some nobility and royalty) would probably be bothered a bit by the time difference,
b) armies trying to converge on the same target at the same moment.
On that Michigan versus Maine thing, as someone in a city that historically was -0045 from its current timezone, I feel it interesting to point out that DST is closer to local noon than "Standard Time" in the city, versus that cities that define the other edge of the time zone and have local noon closer to Standard Time noon. (Our hour-wide time zones make the question of DST versus Standard Time much more complex than just picking one or the other, when talking about abolishing DST or standardizing only on DST.)
If Google today tells me, "It's now 5PM in Singapore", with no time zones it could just as easily tell me "Regular working hours in Singapore are 12-20".
OK, so that's two numbers to remember rather than one, but come on. Thing is, what a certain time means varies wildly country to country, and from person to person anyway. My Swedish friends eat dinner at 17:30. My friends in southern Europe eat dinner at ~22:00.
Unless I know who I'm calling, and their regular hours I have no idea if it's OK to give them a call at, say, 07:00 or 22:00. So I need extra information about them anyway - and that information wouldn't be harder to package in a world lacking time zones. In fact, it would be easier, since it'd contain only one element (times available) rather than two (times available plus timezone).
This doesn't really solve the problems with times, it just moves them from times to dates.
The point is that they already have to, since working hours are, in fact, not identical between neither regions nor people within a region.
That said, I'm not saying that we should abolish time zones. I'm just saying that that article is stupid and fighting a straw man.
For railroads, even at 40 kph, an east-west train would be subject to time shift (not in the Lorentz sense, it would just keep switching "timezones" too quickly). Given that the primary security element was "this train is supposed to pass this set of switches between this and that time and wait there, else it risks colliding with that other train running opposite," both accurate timekeeping and geographically wider timezones were needed (as in "the railroad will use its own time, Prague's lunchtimes notwithstanding").
Time zones were implemented in the United States in 1883. This was well after the use of telegraphs had become widespread, and after the invention of the telephone. While the telephone would not by able to make coast-to-coast calls for another few decades, the idea of communicating with people in other cities was already becoming commonplace.
My point was that the "messy" system the Times article describes would already have seemed reasonable to everyone, who already knew that people in other cities would have different working hours. What annoyed people was the "flattening" of the time zones, making it such that all the cities had to now synchronize their clocks to railway time, no matter what their local noon was. But this is the opposite of the point that the "one global time" advocate thinks he's making.
(Edit: Combining both your replies I think that may actually be your point)
That's another problem that needs to be fixed on its own, by moving the school schedules back an hour or two and making older grades start later instead of earlier. There has been enough research showing that the current schedule is horrible for learning.
