UTC Is Enough for Everyone, Right?
zachholman.com
zachholman.com
For example, if you store time in TAI then you'll have to recompute all other future times as leap seconds are announced.
Computing future times in TAI from user inputs in wall clock time is fraught, so I guess you can't store TAI in those cases.
For a calendar app, since users want to deal in wall clock time, you have to store time with timezone and with leap seconds (so UTC + time zone). And you have to store timezone, not offset to UTC -- timezones can change.
At least internally, however, dealing in TAI can be helpful[0].
Also, IIRC there's a proposal to redefine UTC as without leap seconds[1]... That scares me. Users really need wall clock time.
The continued existence of TAI was questioned in a 2007 letter from the BIPM to the ITU-R which stated "In the case of a redefinition of UTC without leap seconds, the CCTF would consider discussing the possibility of suppressing TAI, as it would remain parallel to the continuous UTC."[16]
Why would getting rid of leap seconds from UTC be a problem for that?
The reason there are leap seconds is nothing to do with wall clock time, it's because some people feel the time ought to be intimately connected to the Earth's rotation, but the Earth doesn't oblige by rotating steadily.
In my view the people demanding this relationship be maintained ought to take responsibility for fixing it from their side. Speed up or slow down the Earth. Can't? Too bad then, but don't expect us to keep fiddling with the clocks.
You are probably thinking of sun transit time, "solar noon", the moment in each day when the sun appears to be "highest" in the sky. This varies of course by position on the Earth, it's how people set "noon" when they didn't need to agree with anybody more than a horse ride's distance away what the time was. So, let's say at least 200 years or more ago.
Do you know when solar noon is where you live now? No? Because it's irrelevant. Huge numbers of people live in places where the solar noon changes by an entire hour twice a year for no sensible reason. Does this cause a huge problem? No, there's a slightly elevated rate of road accidents and things like that, but nothing major. A few seconds per decade is _nothing_.
"it is very difficult to predict — especially the future."
Some Google database systems rely on tight time synchronization to order update events, so they had to have a global monotonic clock.
2018-05-26T13:45:21+02:00
Will never change, regardless how many time zone changes you may have. What does change is the method to compute the time difference. So can you say how many days, hours, minutes, seconds ago that was from:
2043-02-12T11:15:16+02:00
You won’t be able to, because then you have to account for leap seconds, etc.
Also “next Tuesday” does have to take into account the time zone as you may need to deal with daylight saving time.
However “next Tuesday” is not a date-time, but a relative difference from where you are now and by pre-calculating you lose information.
Also relevant, in such cases storing the time zone doesn’t help because the user himself might travel and next Tuesday at 7:00 can remain the same, no matter what time zone you’re talking about.
a) "I'll be there in 12 hours", implication being that if there happens to be a DST change, it doesn't matter.
and relative calendar time
b) "I'll meet you 15:00 next monday".
Both of which are valid.
What's interesting is: which of these is most useful in programming, generally? Which should the APIs make easier, or even cater for at all?
I would submit that most applications only care about "physical time"[1], but specifically [b]logging[/b] is actually really interested in calendar time. Fortunately, with logging there's so much volume that you can usually tell pretty easily when there's been a discontinuous time event -- it's a pain in the ass to rebuild timestamps, post hoc, though.
[1] Calender-type application is actually pretty niche IME. Opinion may vary.
It will respective to the local time though if a state decides to stop honoring DST or changes TZ.
Ah yes, American Atlas: United States Latitudes, Longitudes, Time Changes and Time Zones 5th Edition by Thomas G. Shanks 448 pages.
Covers probably well over 100K locations each with its own history of timekeeping.
Then adapting for local time will screw any schedule not pegged to local time (even for stuff as trivial as following an international event)
Time is hard.
So you really need to store {datetime, timezone_name}.
It gets tricky when you don't know the timezone... For example, you're on a plane with your devices in airplane mode and no wifi connectivity, and you want to create a calendar event in destination time... The UI had better let you specify a TZ, and you'll have to know what it is. Whereas if you want until you land you can just let your devices figure out what TZ you're in and spare you the bother of thinking about it. That's an unlikely edge case, but the UI should really let you input a TZ if you want to. Perhaps the UI should insist on you entering a TZ if you're in airplane mode.
For the case you propose, I read it as a "meeting" planned at a point in the future. In this case storing the start of the meeting as a bare timestamp is inappropriate design. What really should be encoded is the set of rules for identifying the proper timestamp. There was an existing standard mentioned for that which I'd use as a starting point if designing or implementing (if I chose their design) such a system.
Form follows function. If the concept of “10 AM on Saturday” is important to your users, model the software in line with that domain knowledge. All problems are bounded by context, and knowing the boundaries makes designs simplier and easier to manage.
Specifically, future events which aren't tied to a geographical location, and ones which are. And in the latter case, determining which single location it should be pegged to.
A: "We'll have a global phone call to discuss this crisis in exactly X hours from now."
B: "The keynote for the convention in CityName will occur at 3pm."
I.e Does "Last 2 days" indicate: A. Last 48 hours? B. Yesterday + Today up to now C. Yesterday + the day before.
This is a difficult subject.
Recurrence is especially tough to model in a database.
Often the user means "same day of the week, four or five weeks from now".
Gets it right for you. If I mean today, I say today. This is especially true when I'm talking to a computer.
Sometimes we need to use non-human language to communicate intent correctly to a computer, but we shouldn't let that redefine perfectly good and well established human language.
Your definition has the same issue that mine does, just with sunrise being the time around which the meaning of tomorrow is unclear. How high does the sun have to be before "today" becomes defined and the meaning of "noon tomorrow" shifts by 24 hours? If I wake up before sunrise, does tonight refer to now or to after the next sunset?
There's a certain amount of ambiguity inherent to the English language.
I think using midnight as the anchor for the today/tomorrow distinction is a lot less confusing and ambiguous than having today/tomorrow not tied to the current date.
/folks up north
Just print the date and time.
The absolute point in time relied on future knowledge that did not yet exist, that invalidated any previous estimate of when it would occur. An external timezone reference (the Olsen DB) must be continually updated and separately referenced
Of course, if you have a meeting that spans timezones, this is unavoidable. I think the real solution actually lies in how the meeting time is expressed to the user so they don't have misconceptions about it.
If the timezone changes under my feet the unix timestamp might suddenly not refer to my birtday anymore.
Watching people struggle with this is frustrating.
Also I currently work with frontend and while it is no surprise that JavaScript has messed this up badly [0] it surprised me when I realised that a certain large UI framework had a) messed it up b) didn't realize it and tried to close it down when people tried to help.
[0]: they copied Javas first broken Date handling and suddenly they were stuck with it IIRC.
Edit: heh, double-ninjaed
After a heckuva lotta research and reading we determined that we needed to store the scheduled meeting time using two values; the local datetime and the desired timezone eg.
scheduledAt: 2018-05-29T23:41:16.167 scheduledAtZone: Europe/London
Everything else in the system like created, updated, ended data is stored using UTC and transposed on the client using the user's stored time zone preference. eg.
createdAt: 2018-05-29T22:41:16.167Z
The application server your app is running on of course needs to run on Etc/UTC but with that in place (so far...touch wood) we haven't had a problem in our usage.
In local time would be “my meeting starts at xxx”. Leap seconds schould not be involved there, and neither the system time. The users aren’t going to be glad you’re doing that.
When I say "becomes a lot of fun" what I actually mean is that this observation lets us understand very quickly that the problem is not generally solvable. One way or another, somebody's 9 o'clock meeting is going to suddenly take place at 10. Having accepted that, we can push through the idealism and start working actual solutions like the one you described - have the user attach the regularly scheduled meeting time specifically to the UK or to the US.
very funny things happen when there is a shared physical resource e.g. a booked meeting room, and you have a bunch of people schedule meetings with different reference time zones.
ah, and if you think this creates havoc only for a the few weeks while the TZs are out of sync, remember that in the southern hemisphere DST is applied in "reverse"
It's also interesting that since this doesn't happen frequently enough it's usually hard to develop a good way to get out of it.
"The timezone you have used to define this booking has been altered, and the booking cannot be updated due to unavailability of the resource XXXX. Please choose a new time for this booking."
In my country the train stops for one hour at the spring DST change and just waits for time to pass to account for the "missing" hour and not mess up the schedules by arriving one hour earlier.
Heheh, exactly. We're currently debating how best to implement this since this one is more a UI issue than a UTC/Time issue.
For example if the user wants to schedule a call at 2pm New York time (UTC-4) we need to show them the consequences of dialling a participant in the UK (UTC+1) and even more so someone in Sydney (UTC+10).
If you use your ZonedDateTime classes carefully in your code (or equivalents if not using Java) then your app does take care of the DST changes. You can then show the user the scheduled time for not just the person making the creating the event but for every participant - ultimately the user has to decide what compromise to make when scheduling events across time zones and DST changes.
My side doesn't observe DST. The other side does. The border keeps different Summer and Winter hours.
Trying to figure out when I need to leave to make sure I get to the border during its open hours to get through, and then when I need to leave (in local time on the other side) to get back through during the open hours is an extremely tedious problem.
Worst part is crossing the border is just me driving South. My longitude doesn't really change.
Time is an illusion.
Lunchtime doubly so.
— Douglas AdamsHow does that work when the same local datetime happens twice during a DST switch, or when a local datetime is skipped during the other side of a DST switch?
There is still a caveat, though. Locations can change timezone. Sometimes they do it fairly often (like every few years). You need access to a good timezone/location database that is updated regularly :-(
When we were doing this project, I was really surprised at how often we got problems. If you sell things all over the world (there are golf courses in ridiculous places), the probability that you will stumble into an anomaly is surprisingly high. Alas, this project was not a commercial success as the margins on tee times are quite small (and the tee time services you have to work with are often quite badly written). But it was quite fun to work on.
I hate time.
The tricky thing to realize is that this is not a datetime. This is more of a contract/condition saying "when localtime will be at this value" or better yet "when localtime will have exceeded this value for the first time" because you know someone will put a date on a leap second or missing DST hour at one point.
It's unfortunate how few libraries exist to handle abstract datetime constructs, and how frequently programming environments screw this up. The only one I know of that doesn't mince concepts is Java 8 Time [1], where points-on-timeline timestamps are clearly separate from human-centric calendrical concepts like Time-of-Day (LocalTime) and Month-Day without a year, so there's an appropriate datatype to model lots of common use-cases of date math.
[1] https://docs.oracle.com/javase/8/docs/api/java/time/package-...
My son’s friend in school was born on February 29. We could go through the time pedantry and claim that she is 1 year old (she is 6), or pick an arbritrary moment in time (say March 1, except for leap year) and get on with the party.
If you’re plotting a satellite course, the details matter, but many, if not most use cases require consistency over precision.
Indeed, your son's friend's age is an ambiguous notion, Hence the need of a more precise contract than a simple date.
For the past and present, UTC is fine, and a source timezone if necessary. To track the exact instant when something happened to me, just storing UTC is fine. If I want to know what where the hands on my clock were when that happened, you also store which clock I was using separately (timezone), but this is optional and doesn't prevent accuracy.
For future times, relating to humans, like on a calendar, there's a very important distinction - I want to set appointment when my clock shows a certain time, irrespective of what the timezone rules (Daylight saving time rules can change) are at that point. Here, storing the UTC time for my appointment according to today's rules is a problem - you must simply store what I expect to see on the clock and apply the timezone rules lazily at the last possible minute.
Of course, calendar events in icalendar have the tzdata stored along with them, in theory, so they should never change unless your client updates them. Which leads to its own world of fun.
Good example: you, user A, are in a TZ that switches biannually - at one point in the year you lose an hour, at another you experience an hour twice. Now, another user B is also in one of these whacko places and creates a meeting (while experiencing an hour for the second time) or what-have-you for a future time where user A goes through their local groundhog hour. You have a backend server that, for legacy reasons, simply truncates TZ and goes with its own local TZ. That server is in another TZ that has an identity crisis. JS is doing dumb stuff that only JS could do. Does your brain hurt yet? I'm pretty sure that this engineer can now perceive four dimensions.
He didn't receive a bug report until we migrated to UTC. UTC made things worse, somehow. As it turns out UTC is only good for when you care about a machine doing something at some time, or when working relationally.
Store TZ (ideally location, an offset is not a TZ) along your dates. When presenting them include that information, as well as relational ("3 days, 4 hours ago at 00h15 in WA").
Time is nuts.
This sounds exactly like a line out of some Douglas Adams book. Which is perfectly fine as long as no one booking meetings on that app has read any of his books.
> It's most likely because you have twelve joints in your hands: three in each of the four fingers, excluding the thumb. I thought that was pretty nifty to discover. Like, I had never looked at my hands before, really. Hands are really wild, when you think about it.
Probably not. This explanation of duodecimal is really farfetched and I’m pretty sure it arose from someone staring at their hands desperately trying to come up with a way to count 12 on their fingers to explain this. (Ten fingers and two feet seems as likely.)
Clocks are (probably) divided into (two sets of) 12 hours for the same reason feet are divided into 12 inches. Because it’s convenient for everyday use. Subdivisions of 1/12th suck for complex math (if your number system is decimal anyway), but are great for lay use. 12 subunits captures halves, thirds, and quarters, all of which are very intuitive and very common in everyday use.
12ths are handy enough that we have a special word for “12 of something” (dozen) even though our numbering system is decimal.
My understanding is that the etymology of dozen is originally traced back to duodecim (Latin for twelve) via French dozeine. Which is interesting, but doesn't really explain why it's special beyond your observation that it's a highly composite, but comfortably small, number.
French nitpicker here. We now write it "douzaine" but spellings have changed through the ages.
Hmm, how about 14 of something?
You have a fortnight to respond. Though if you take about a sennight longer to think about it, you'll still get a good score.
It is interesting that "dozen" made it into everyday English but other group sizes did not.
Counting that way on one hand and then using the other hand to tally the groups would give you 5 sets of 12 or 60.
Now, that approach would guarantee that your base is a product of two numbers (# fingers * # bones on non-thumb fingers). And, if your non-thumb fingers are roughly equivalent to each other, then that would guarantee it's a product of three numbers (# fingers * # non-thumb fingers * # bones per non-thumb finger). So I would say "it's a product of lots of numbers" does have a lot to do with the origins of base 60. Base 10, of course, is (# hands * # fingers per hand). Base 12 being more factorable than base 10 is just the luck of getting 3 * 4 vs 2 * 5.
You are mistaken. Finger counting by using your thumb against one of the 12 segments of your fingers is common in many asian cultures. It's utterly simple and immensely practical as it allows you to count up to 144 with both hands.
Very funny, but here's the real reason (https://www.etymonline.com/word/second):
> second (n) from Old French seconde, from Medieval Latin secunda, short for secunda pars minuta, "second diminished part," the result of the second division of the hour by sixty (the first being the "prime minute," now called the minute).
Etymonline.com is awesome. I use it several times a day.
- [bio](https://www.etymonline.com/columns/post/bio?ref=etymonline_f...)
scroll scroll scroll nod nod nod scroll scroll scroll
> Recurring events
Whelp, shit just got very very real, and I actually disagree with Zach here:
> If someone held a gun to your head and demanded in the next week you either 1) programmed a comprehensive system that included full support for recurring events, or 2) invent full-scale ready-to-go-to-market cold fusion, then you should abolutely start brushing up on atomic physics.
You should just beat yourself with the gun (or whatever the nearest heavy implement is) immediately, no cause to prolong the pain, you're not Harold.
Yeah, sure, I "got it done" but it was very challenging to maintain for a while. And, of course, I learned well after the fact that what I had designed and implemented had basically, rather poorly, implemented some existing solution / FOSS library (I had essentially written some pieces of the Ruby gem ice_cube without realizing it) that I hadn't been able to find via Google at the time.
GMT-8 is an offset. America/New_York is a timezone.
This becomes important when you want to schedule a meeting on the east coast of the USA in April - Europe and the US change DST on different dates. But if you tell postgres you want a time in a particular zone it will do the calculation correctly. If you use an offset you might turn up an hour late.
It's also useful for disambiguating a local time:
2018-11-04T01:45-05:00 America/New_York 2018-11-04T01:45-04:00 America/New_York
That said, I do think they are mostly around for less noble reasons: they are way easier to serialize than actual time zone rules.
- [postgres/src/timezone at master · postgres/postgres](https://github.com/postgres/postgres/tree/master/src/timezon...)
I'd just like to point out that a lot of RDBMSs support storing date and time alongside timezone information directly without using two separate fields. SQL Server has datetimeoffset, PostgreSQL has timestamp with time zone, and Oracle has timestamp with time zone. I think MySQL does as well, but I seem to recall something strange about it. Or maybe that's just me expecting MySQL to do something weird.
Similarly, most programming languages have support for datetimes with time zones.
It's still all a huge pain in the butt, but you don't need to use two fields and ensure that you use both all the time. Also, you can meaningfully compare datetimes within the same database without translating the timezone if its all in one field.
Also, of course, remember that a even a time with timezone without a date attached to it is inherently ambiguous.
PostgreSQL's "timestamp with time zone" doesn't store timezone, it converts the time to UTC and stores that, and on retrieval converts the value to the connection's time zone.
It's problematic when moving data between systems with different Locale settings. Because ANSI timestamps are stored as 'local' time, timestamps will shift if you read from a DB in New York and write to one in San Francisco. Both will interpret an ANSI SQL timestamp as being in their locale unless told otherwise.
I'd view that as incomplete (rather than ambiguous) until applied to a specific date. "You people in the Hawaii office feel free to join the Boston 2PM call whenever you want" is a fine thing to say even though you don't know what the Hawaii time will be until you know the date.
Times don't have timezones - places have timezones. The idea that time handling is made easier by attaching timezones to times is the cause of so many headaches. Correct time handling involves understanding place - the place where things happen, the place where the user is observing them from, the place where a clock displays a particular time.
Some RDBMSs only support datetimes (timestamps) with time zone, but if you want to aim for complete ANSI compliance you're supposed to allow time with time zone. PostgreSQL, which allows that data type, specifically points out in the doc that you shouldn't use it:
> The type `time with time zone` is defined by the SQL standard, but the definition exhibits properties which lead to questionable usefulness. In most cases, a combination of `date`, `time`, `timestamp without time zone`, and `timestamp with time zone` should provide a complete range of date/time functionality required by any application.
https://www.postgresql.org/docs/current/static/datatype-date...
It's ugly and horrible, but that's life.
They do, but in many languages they're easy to misuse, and I think this is an underappreciated part of the problem. I'd even argue that timezones really aren't that hard, they're hard when you use the wrong abstractions or try to tack them on as an afterthought. Ultimately there's a big lookup table that someone else manages for you (the Olsen database) that gives the current definitions of timezones and how they relate to UTC at various times of the year due to daylight savings changes. Given a local wall-clock time and a timezone name you can use this to unambiguously get the global instant in time it corresponds to.
But a lot of libraries let you ignore or mix up these underlying types, or implicitly convert between them in a way that you may not realize is happening. The biggest problem I've seen by far is that a timezone like America/Los_Angeles is not the same as an offset like -07:00 or a named offset like PDT (the latter is the most confusing and really just needs to stop being used. It has the definition of a static offset in that it means 7 hours behind UTC, but also corresponds to a place which is sometimes on PDT and sometimes PST, and also is usually referred to as just a timezone with nothing to distinguish it from timezones from the Olson database like America/Los_Angeles. And I think it also has a name collision with a timezone in Asia).
As an example of the problems this can cause, say you start with a time like 0:00 March 11 2018 in America/Los_Angeles. If you call the "to_iso861" method in any given time library you may or may not be implicitly converting the timezone to an offset as it'll return "-07:00" or maybe PST (ISO8601 doesn't have anything to say about what a timezone should be, so these are all valid). But now when you parse that again and add 4 hours to it, you'll still have a time with -7 hour offset even though the place you were originally referring to has changed and now has a -8 hour offset.
The javascript Date type is notoriously bad on its own as well, since it implicitly converts everything to the browser's local timezone offset. And moment isn't a whole lot better, the timezone support is tacked on as a separate library and it will happily let you mix up offsets and timezones as well, or let you go back and forth to a Date object which can have that same implicit conversion problem.
The only library I've seen that actually requires you to treat these concepts separately is Joda, which has port as js-joda. The syntax can be a little confusing and the js port is missing good builtin support for locale-aware formatting though, but those are all minor annoyances and well worth it for the better abstractions it gives you. The good news is there's a new builtin time library on the horizon for JS as well which seems to be borrowing from both joda and moment, as well as browser support for Olsen timezones and locale-aware time formatting, so I'm hopeful it will be easier to just "do the right thing" by default in the not too distant future.
and then there is the question of how you would represent a recurring calendar entry between both places.
Now you might care about communication lag, but nothing makes earth unique so you need to handle lag with arbitrary endpoints anyway.
Good read.
You see, UTC, is kinda like another human-made-up timezone. Humans made up some rules, and UTC is a 37 second offset from TAI / International Atomic Time:
Like most things associated with time Leap Seconds are a huge headache to implement properly on computers. If you want some fun watch what various NTP servers around the world do when Leap Seconds roll around. You will see clocks that start to drift for 15 minutes before jumping to the right time, some that wait until 8AM local time on the following day to correct, and some that just go crazy. And of course you have Google's clock smearing across most of a day.
IIRC there was one major earthquake that caused a sooner than expected Leap Second adjustment.
Fun fact: GPS, NTP, and many similar timing formats have flags in the signal that warn clients of upcoming leap second events. Few receivers pay attention to them however.
As a note, clock smearing is a non-standard hack invented by Google, because most programs are too broken to handle the leap second warning event and inserting/deleting a second properly, per designed. And you shall never add a clock smearing server to the www.pool.ntp.org.
But internal changes in the Earth can also cause changes in the rotation period. For instance the 2011 Tohoku earthquake shortened the day by 1.8 us [1].
[1] https://www.earthobservatory.sg/blog/how-did-2011-tohoku-ear...
Note that if the day slows by 5.5 ms from 24 hours, then we need an average of more than one leap second per 6 months to keep up. Per https://en.wikipedia.org/wiki/Earth%27s_rotation the Earth's rotation changed by 1.7 ms in the last century, an average of 2.3 ms in last thousand, and it is being affected by a variety of causes right now.
I recently ran into a completely novel time bug while working with Excel file for GoodGrids. In Excel files, date and time values are stored as epoch time. But you can not tell what time a particular number represents until you check whether the file was made with Excel on Windows or on the Mac. It turns out, the developers chose a different start of the epoch on these two platforms.
A while ago I came to the conclusion that time is simple from any one perspective, but complicated when you try to handle all possible perspective. Try to explain the complexities of time to someone who does not travel, resides in the same timezone all of their life, and does not need to coordinate with anyone outside of their timezone. For them, the rules that govern time are pretty easy.
Universal time is in part about trying to order events in a strict order. Probelm is, nobody observed that order. Later we infer things about the system based on this chronology but it’s completely fictitious and we have to stretch our brains to explain the state of the system.
The Java Memory Model, and subsequently several other languages, agreed on “happens before” semantics. We don’t care what order certain things occurred in as long as these key events happen in the right order. Because those events cause the other events or are caused by them. Some transactional models have a flavor of this as well. This write happened based on a decision made by observing all of the transactions up to N, which may or may not result in a rollback because N+1 overwrote a read value.
I can’t help thinking that our logs should show something like “customer saw their balance was $102.75 and withdrew $100, and on another server a payment for $55 was honored around the same time, which is why they are now overdrawn”. The two events were independent, and maybe we should remember them the way the distributed system experienced them.
Or maybe that’s even harder to reason about than the fiction we use now...
Still doesn’t rule out bad tools but it doesn’t paint a good prognosis.
Not the only reason I use a credit union these days.
$ cal 9 1752
September 1752
Su Mo Tu We Th Fr Sa
1 2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
edit: I should have searched (http://mentalfloss.com/article/51370/why-our-calendars-skipp...)
OK, I guess this is a joke, but this actually began to happen during the Industrial Revolution, when factory owners were obliged, as part of worker training, to teach workers how to read a clock.
The Brits did this for their railroad in 1847. Time balls were used to synchronise clocks before telegraph and radio.
https://en.wikipedia.org/wiki/Time_ball
On clock accuracy, I was reading last night about time dilation due to gravity, and the difference in time rates from points less than one meter apart in height on earth have been experimentally verified.
Admittedly you can’t schedule a phone call or chat since the latency is too great but if you wanted to schedule an event to occur in say a software system on both planetary bodies at the same time your software or time library would need awareness of celestial mechanics...sounds like a fun problem :)
It is truly nightmarish stuff. I am convinced you could run a very profitable consultancy specializing in debugging date and time related problems in people's systems.
The reason why we use numbers like 12 and 60 and 360 in time and length, from ancient times onwards to today, is because these numbers have many divisors, meaning that they can be divided many different ways without needing decimals.
12 can be divided by 1, 2, 3, 4, 6, 12 (i.e., it can be divided in half, into thirds, fourths, sixths). By comparison, you can't cleanly divide 10 into thirds or fourths without using decimals.
60 can be divided a whole bunch of ways: it can be divided by 1,2,3,4,5,6,10,12,15,20,30,60. The same is true for 360 (e.g. degrees in a circle).
Even in the modern era, where we understand decimals and everyone is trained on them, it's convenient to be able to perform common operations on common units without having to involve decimals. It's convenient that an hour can be divided into three 20-minute periods, or two 30-minute periods, or six 10-minute periods, and so on.
1. TAI, and systems that have a fixed 1-to-1 mapping to it (e.g., GPS).
2. Systems that are generally unable to calculate how many seconds will elapse until your next birthday. UTC is in this category.
Articles like this spend a lot of time on the varying degrees of insanity in category 2. But I would rather start with category 1 and negotiate any additional complexity from there.
Without looking it up, I would say the last change happened when North Korea decided to sync its timezone with South Korea... or have they reverted that since Trump cancelled their summit?
It's actually pretty cool- all of this is discussed on the tz mailing list, so you can see how it all works yourself! https://mm.icann.org/pipermail/tz/
> From 1994 through 2017 Namibia observed DST in winter, not summer.
> In 1946/7 Czechoslovakia also observed negative DST in winter.
2018d had a change to palestine's DST date (a week earlier than usual), Casey Station moving from +11 to +08 and a few other historical changes/fixes.
And I think no one mentioned the very related Computerphile video yet: "The Problem with Time & Timezones " https://www.youtube.com/watch?v=-5wpm-gesOY
Same topic, equally entertaining (not AS geeky though).
:P
I have nothing to do with it but this is an open source automation project I have bookmarked with some of those functions:
https://github.com/jaskie/PlayoutAutomation/blob/develop/TAS...
Lots of hassles.
I guess I get to play the part of the second person…
So: the first time I ever found a paragraph like the one the GP has quoted, happened on the same site I've ever been on where the autoplaying videos are making my whole system (including typing this comment) lag worse than any other site I've been on.
At least it gave me one good idea for the Extension I'm Making One Day™: watch the CPU and if the current page is killing it and it has autoplaying videos and/or CSS animations, automatically kill both.
In the meantime, I had to close the article as it was unreadable. (Wow, getting my low typing latency back is wonderful!)
So, your build system will be scheduling daily builds at the same time every day, and then suddenly after a DST change those builds will be an hour off from when you expect them. But here's the even more fun part. If you simply happen to edit and then save one build definition after the DST switch then it'll be saved with a different UTC time (due to the different UTC offset) and it'll run at the correct local time of day.
Day is the basic measure. Deciday = day/10. (=~ 2.4 hour) Centiday = day/100
Either could be used in place of the old fashioned hour.
Milliday = day/1000 (=~ 84 seconds)
Milliday seems like a good replacement for the traditional minute.
Centimilliday to replace seconds? It's a but unwieldy but could be abbreviated as cmd (similar to the commonly used 'sec.')
Years are a little troublesome. However with sufficient energy input a Kiloyear could be made to be 3 years. With sufficient precision (and perhaps occasional correction) it could resolve that leap year and occasional leap second issue.
There would be some ramifications. For example the Newton is defined in terms of seconds so there are some units beyond pure time that would also require revision.
Let's get rid of this madness of 24 hours, 60 minutes and 60 seconds. And 365.2425 days was just plain wrong from day 1.
RFC 2606 ("Reserved Top Level DNS Names") not RFC 2616 ("Hypertext Transfer Protocol -- HTTP/1.1")? I would have gone with the latter.
Related: I just noticed Cloudflare's DNS service (1.1.1.1) follows the suggestion in RFC 2606 and resolves *.localhost to 127.0.0.1. That can be handy for local web development etc. There are some other wildcard domains that resolve to 127.0.01 but I usually can't remember them.
Birthdays (as the article mentioned) are not points in time and mean different things depending on where you are, so best stored as a year-month-day combo without any zone information.
Past times are not that big of an issue actually, just use UTC and convert to local time to display, but calendars schedule for the future, and you can't always calculate a future time in UTC.
In e.g. distributed system where monotony and ordering is important UT1 would actually be even better than UTC, as UTC has occasional jumps (hence the workarounds, like googles skewed NTP)
In countries with significant amounts of legal leaves (e.g. most of europe), tuesdays and thursdays are also very nice as "burning" a single leave day provides for a 4 days weekend (and 3 days week). French even has an expression for this: "faire le pont" (bridging between holiday and weekend).
2012: https://www.theatlantic.com/national/archive/2012/07/serious...
2007: https://www.inc.com/news/articles/200706/independence.html
1990: https://www.nytimes.com/1990/07/04/garden/and-thank-god-it-s... (NYT)
Since everything is relative, my preference for recording accurate historical time is microseconds since TAI0. Everything else prior and future is an estimate.
Users can and do configure different time zones than where they're actually located, e.g. if someone in India is working with a team in the UK, they'll probably have Indian time on their local clock, but select UK in their user profile.
Also, some people travel.
The Unix Epoch does not handle leap seconds (time just rewinds). Google's time smearing approach is a great hack, but trades one issue for another.
This is a niche case in high resolution time, auditing and security considerations.
In this way, we can tell the exact time something happened in the past, no matter how timezones/DST changes, but we can also have future events stored according to people's expectations.
I'm not aware of any physicists debating this. If time didn't exist, there wouldn't be a physical dimension for it, and everything would be at a fixed position in 3-dimensional space.
It's not necessarily the case. Maybe the universe is just an tangled graph of events. Maybe the dimensionality of spacetime only emerges as an asymptotic behavior of this graph and it breaks down in small scales. In this view time doesn't exist at a microscopic level.
Highlight of the article! Even though I disagree with certain bits, the article in itself helps explain how to think about programming time in a project.
I find it best to stick with UTC. Otherwise there's too much ambiguity. Especially when we're all pretending to be somewhere that we're really not.
1527698540
There are cases where you have to make a judgement call, one way or another. Take the case where I invite you to a weekly meeting at 2pm. You live in a place with DST, I don't. DST happens and... is the meeting at 2pm, or 3pm, or what? Google Calendar (and many others) basically say whoever owns the event wins, so our "regular" meeting time would track however you go through life (at least in terms of DST), so times might change for you but not me, and vice versa.
Anyway, yeah, there's some really odd interactions once you start digging deeper.
Wrong:
> zachholman.com/video/utc-title.mp4
I'm surprised the author didn't mention Railway time. The standardization of time did not begin in the USA in 1883, it began in England in 1840. Before then, sundials, and later a local mean time, was used to determine local time. Railroads published almanacs with different local times, and instructions on how to reset a watch along a route to know what time it was. However, the small changes in time, or even differently timed sunsets, created problems and accidents, so to solve this they used the newly invented telegraph service along the railroad's telegraphic lines to synchronize clocks to the official time at Greenwich. This method to synchronize time then spread to India and then the United States. It was in 1880 that a law passed in Great Britain finally made the new time official across the whole country.
However, as the attached article shows, neither GMT nor UTC solve everything. When humans are involved there will always be mistakes unless things are simplified for them.
In all seriousness, a great collection of advice on time. Bookmarked.
TAI if you can work it out :)
Turning off autoplay (e.g. media.autoplay.enabled in Firefox) fixed it. You can still play each video by right-clicking on it.
> it is predictable that some clueless commenter on Hacker News will complain that this page has autoplaying video on it
Reader mode didn’t work, so I gave up.
(Finna hang on to my videos, though! Life doesn't always need to be so one dimensional, particularly for one-offs like this.)
It's actually the reverse: base twelve is more elegant than base ten[0]. The only reason we think otherwise is that we're used to using base ten.
0: ½ in base twelve is .6; ⅓ in base twelve is .4, not .333333…; ¼ is .3; 1/6 is .2, not .166667
I also don’t understand why modern English doesn’t take advantage of them like modern German does.
But I wish we could all just use one time. For some, midday would be 12, and for others it might be 19, but we already all use the same dates regardless of whether February is winter for one location or summer for another.
We are still trying to dig ourselves out of old systems where “today” and “yesterday” are logically different and we hide the problems by assuming most users are asleep at midnight. Most new systems don’t have this problem but older ones equate “tomorrow” with “start of business the day after tomorrow”.
I think there is a simple plan that isn't disruptive. Simply require that all times be listed in both formats. For example, 9:00 am EDT (13:00 UTC) for all printed times on all signs, etc. moving forward from some day in the future. Eventually, we can drop the first as people adjust. (This is already how we re-number or rename highway exits)
This doesn't help in any way, shape or form. You have pissed off billions of people who have had to re-learn custom times for things, you have caused the weekday to flip in the middle of the day for billions of people, and you STILL haven't solved the problem of "Can I call Uncle Steve in Melbourne, or is he sleeping right now?"
There is no way to solve that problem of Uncle Steve (imo). But there is no difference in saying Steve is +8 hours so our noon is his 20:00 and or saying we should only call Steve between 03:00 and 20:00 UTC. It is an offset either way. It is only jarring to think that way now because it is the one way people have.
There is also the problem of someone driving across the US and suddenly they pass an invisible line and now it is one hour in the past or the future. The day changing while you work already happens for everyone working 3rd shift.
Billions of dollars in waste and confusion happen today because of forgetting about timezones. One study suggests that international trade is decreased by 5% per timezone between countries.
There's probably some research somewhere estimating the cost to business (or loss of revenue) from mistakes in doing timezone conversions. In the simplest case, if you have a business call with someone halfway around the world, and one of you has recently gone into or out of daylight savings time, then there's a good chance the call will not happen when it should. Or perhaps you were supposed to be watching a political debate online at a given time so you could provide instant advice and feedback to advisors present in the debate, but you missed it because you didn't realize they had left DST a week before your location does.
I could go on and on with examples of the human cost to keeping the current system.
So let me say this: _coming up with the ideal system is not hard_. But how will you transition the world from its current state to this ideal state? Consider that the metric system (or SI), which is much better than the US system of measures, has still not been adopted in the US. Why? Because the problem of transitioning between systems is called politics.
But if you do much international travel, at some point you will encounter the problem where your various calendars, clocks, and other tools don't do the right thing (perhaps they get incorrect location information, or any number of other problems occur).
Then you have dis-information. If you don't realize it, then you will suffer by missing something important or wasting your time.
The tools are far from infallible now, and there's really no hope that they will ever work correctly.
I'll take "better" even if better != perfect.
Also that system will probably devolve into defacto timezones without actual definitions where business in nearby areas decide on what constitutes reasonable hours based on businesses around them and the relative solar time but instead of reasonably crisp boundaries like you have today defined on a map it'll be a slow bleed and interspersing between multiple sets of '9-5' hours.