
UTC Is Enough for Everyone, Right? - bpierre
https://zachholman.com/talk/utc-is-enough-for-everyone-right
======
0x0
So the article seems to imply you should store all timestamps as UTC (with an
additional timezone string ID). But for events in the _future_ that needs to
happen on a specific "wall clock point in time", it might be better to
actually store the yyyy-mm-dd hh:mm:ss as a string with a timezone next to it,
because timezones can and do change often unpredictably. If you pre-calculate
what "4.00pm next August 1st" is as a UTC timestamp today, and the timezone
rules are updated between now and then, your UTC timestamp may end up being
incorrect. I guess you could have an additional "precalculated-utc-timestamp"
column but regularly re-calculate this from the "yyyy-mm-dd hh:mm:ss +
timezoneID" (especially when you upgrade your Olson tzdata).

~~~
bad_user
Actually the meaning of a date like:

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.

~~~
0x0
It depends. It could be a meeting in a particular city at 4pm local time. A
"+02:00" or "-05:00" specifier is insufficient because the government of the
particular city/country might change the time zone rules between now and when
the event is to occur. So you really need to store "2018-08-01 16:00:00
America/Argentina/Buenos Aires" for example, because maybe after 2018-06-01
they decided to go for "-05:30".

~~~
lomnakkus
Indeed. There's a concept of relative physical time

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.

------
dpark
> _If you 're like me and immediately said ohhhhhhhhhhhh, so THAT'S why
> there's twelve hours in a day! and immediately followed it up with: wait,
> why the fuck are they using twelve instead of ten? ..._

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

~~~
_asummers
I might not be remembering my History of Math correctly, but my recollection
is that the Babylonians used Base 60, and 12 is an even subdivision of that. I
also recall other Asian number systems having base 12 in some capacity, so
there may be something to the counting methodology he outlined if it showed up
in a few separate parts of the world.

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.

~~~
goodpass
Wait, doesn’t that just give you 25?

~~~
_asummers
No, counting to 12 using the sections between your knuckles of your 4 fingers
using your thumb on same hand will give you 3x4 and then 5 of those is 60. If
you were doing fingers as a single digit, you'd get 25, though.

------
akkartik
_" Did you hear about the clock maker who was the first to add a second hand
to a clock? His first prototype was a complete failure, but he got it working
the second time."_

Very funny, but here's the real reason
([https://www.etymonline.com/word/second](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.

~~~
agumonkey
One of my most visited and favorited website. Donate to the author.

~~~
aeorgnoieang
The author's bio is great:

\-
[bio]([https://www.etymonline.com/columns/post/bio?ref=etymonline_f...](https://www.etymonline.com/columns/post/bio?ref=etymonline_footer))

------
masklinn
Having dealt with that crap… _that should be an interesting read_

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

~~~
scruple
Yeah. I've lived through this scenario (implement recurring events based on a
calendar system in very little time). And even though I definitely had a
longer runway than a week (a whole month! on top of the work that I already
had on my plate), I would still agree to take the beating immediately if I was
presented with that situation again.

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.

------
erpellan
Postgres have done a really good job here. It not only understands offsets
(which most devs think are timezones) it also understands timezones. What's
the difference?

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.

~~~
jobigoud
What's the point of unqualified offsets like that anyway? You either use UTC
or a local time in the appropriate tz.

~~~
x1798DE
They are useful for when you want the semantics of UTC but still a human
readable time. One example is logs that people will actually read. People have
a hard time doing mental math but 14:00-05:00 is just as valid as 19:00+00:00
and easier for people in Eastern Time.

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.

------
da_chicken
> Properly storing timezone-aware times

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.

~~~
jameshart
Erp. This sentence made me wince.

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

~~~
da_chicken
Yeah, that's kind of an issue with the ANSI standard. It specifically allows
time with time zone.

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...](https://www.postgresql.org/docs/current/static/datatype-
datetime.html)

------
setquk
Slightly off topic but I wonder how you handle time where dilation is present.
For example if a spacecraft travels to mars and there is mars local time, plus
time dilation from the journey, when does a transmission start from a
reference frame? Not UTC related for sure! Or is it? And then what happens if
someone else goes there in a different orbital pattern and the dilation is
different.

and then there is the question of how you would represent a recurring calendar
entry between both places.

~~~
jetrink
This is a very old problem and not limited to spacecraft. If you sail around
the world eastward, each of your days is slightly shorter than the days of
your countrymen and by the time you get home, you will have experienced a full
additional day-night cycle. I think the solutions would be the same: separate
timekeeping standards where it makes sense, like Mars, and frequent
corrections to spaceships' clocks to keep in step with a universal standard
like UTC as sailing ships used to do[1].

1\.
[https://en.wikipedia.org/wiki/Noon_Gun#Time_signalling](https://en.wikipedia.org/wiki/Noon_Gun#Time_signalling)

~~~
cryptonector
That was part of the plot of Around the World in 80 Days...

------
pquerna
Love this article, but one thing it skipped on was more in-depth on Leap
Seconds.

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:

[https://en.wikipedia.org/wiki/International_Atomic_Time](https://en.wikipedia.org/wiki/International_Atomic_Time)

~~~
milesvp
Right? And that that 37 second offset will change from year to year? I was
waiting for the bombshell, that some minutes actually have 61 seconds in them,
and some have 59 seconds (though it occurs to me that I don't know if
astronomers ever add or subtract more than a second for any given clock
adjustment).

~~~
welterde
The goal is to always keep UTC within one second of UT1. Short of very drastic
events I don't think it will ever be neccessary to introduce more than one
leapseconds in a fairly long time interval. And even if it was, I would think
that they would do seperate leapseconds events some time apart.

~~~
jandrese
There are two official primary times a Leap Second can occur. December 31 and
June 30. There are provisions for more slots, but they're not really expected
to ever be used.

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.

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

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.

------
koliber
Four days ago I saw an excellent presentation about the trickeries of time,
dates, and timezones at DjangoCon Europe. It was by Russell Keith-Magee and is
short, to the point, and super informative:
[https://www.youtube.com/watch?v=qabriMQ1SYs](https://www.youtube.com/watch?v=qabriMQ1SYs)

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.

------
hinkley
I have been thinking a lot lately that we are trying to solve class of XY
Problem.

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

~~~
TylerE
Every bank I've ever been a sucker-err-customer of seemed to use whichever
order results in the most fees.

Not the only reason I use a credit union these days.

~~~
jhayward
There used to be a law against that in the US, but the GOP repealed it early
in Trump's first year.

~~~
IncRnd
What was the law name or number?

~~~
jhayward
Federal Reserve rules published under regulation E.

------
SaladFork
My favorite date quirk not mentioned in the article or here yet is the month
of September 1752. If you're on a *nix/Mac machine, try this command:

    
    
      $ cal 9 1752
    

What you'll see is:

    
    
         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
    

No, there's not a bug in `cal`, this is correct ;)

~~~
rbosinger
That was fun. So what happened in 1752?

edit: I should have searched ([http://mentalfloss.com/article/51370/why-our-
calendars-skipp...](http://mentalfloss.com/article/51370/why-our-calendars-
skipped-11-days-1752))

------
emodendroket
> Probably around this time your first boss's ancestors were also discovering
> minutes as a good way to make sure your ancestors got to work on time:
> "You're exactly 56 minutes late today, Holman, what the fuck is wrong with
> you? Go shave the sheep!"

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.

------
foobar1962
> [1883] ... a bunch of rich, white railroad tycoons met at a fancy Chicago
> hotel to agree on a standard timezone so their trains would work better
> together...

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

~~~
cup-of-tea
Indeed, I thought it was well known that Britain was the first to standardise
time and that it was done for the railway.

------
leonroy
One thing I’d love to know is how the heck as software devs will we manage a
future moon or Martian colony with its own set of discrete time zones...

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

------
nsxwolf
In my 20 years of working with software and distributed architectures, no
problems have been harder than working with time zones and calendars.

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.

~~~
zrobotics
That would be profitable, but I'm not convinced anyone could stomach that job
without going insane. Maybe a year if you were extremely hardy, but I'd be
running for the padded cell after 3 months of dealing with nothing else.

------
Pyxl101
> Egypt was the first ones to really start doing this: they had a duodecimal
> system already, so that's why it was split as base twelve, or our two parts
> of twelve hours in a day. If you're like me and immediately said
> ohhhhhhhhhhhh, so THAT'S why there's twelve hours in a day!

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.

------
rbonvall
Ironically, the article is dated "Spring 2018", which for half the planet
doesn't happen yet :)

------
marshray
There are only two types of time systems:

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.

~~~
TorKlingberg
The exact start of my birthday depends on where will be at the time. It starts
and ends at midnight in the current timezone. With some clever time zone
jumping my birthday could start twice or more in the same year. Also if I was
born on February 29, you need to move it Feb 28 or March 1 on non-leap years.

------
netsharc
> This stuff moves a lot, too: the tz database (also known as the Olson
> database), which is the listing of timezone rules we use as programmers to
> calm this chaos, gets updated many times a year.

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?

~~~
holman
I think it's one of the more recent changes.

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/](https://mm.icann.org/pipermail/tz/)

~~~
politelemon
Thanks that's a great link. Indeed as you said I'm learning quite a lot about
how it works just from this thread which started about the Western Greenland
timezone!

[https://mm.icann.org/pipermail/tz/2017-December/025606.html](https://mm.icann.org/pipermail/tz/2017-December/025606.html)

------
psteinweber
I really enjoyed this.

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](https://www.youtube.com/watch?v=-5wpm-gesOY)

Same topic, equally entertaining (not AS geeky though).

------
slater
We could've all switched to Swatch™ Internet .Beat Time™ by now, but nooooo,
we wanna stick with all this mess instead!

:P

------
john00088876
If you think calendar apps are a pain try television broadcast automation...
frame accuracy instead of per second, with fractional frame rates (29.97,
23.98, fps) and a mix of content of different frame rates on the same playlist
and conversion to different frame rate on the way out, plus operators in a
different timezone than the channel and the need to handle timezone changes
without messing things up on air.

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...](https://github.com/jaskie/PlayoutAutomation/blob/develop/TAS.Common/SMPTETimecodeExtensions.cs)

Lots of hassles.

------
ris
If you want a technical audience to read your page, get rid of the videos and
unnecessary animations.

~~~
saagarjha
> It’s so predictable that developers will pooh-pooh having to write timezone
> code, almost as much as it is predictable that some clueless commenter on
> Hacker News will complain that this page has autoplaying video on it. And
> then someone will calmly quote this passage in response, quietly pleased
> with themselves that the initial commenter was rude and certainly didn’t
> read the post at all. Then a third person will chime in on the thread saying
> the author was playing you all like a fiddle anyway, and the real problem is
> that the post was way too long to start with.

I guess I get to play the part of the second person…

~~~
zifnab06
The author played us all like a fiddle.

~~~
exikyut
He's playing my laptop like a fiddle, too, a really high-pitched one: all the
videos are keeping the CPU at 100% CPU so I had to downclock everything to
keep the system below 64°C.

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

------
joshstrange
Implementing recurring events is a nightmare. Also working with potentially 4
different timezones in a single situation is terrible. We have instances where
we need to display a time in a browser but we have to take into account the
browser's timezone (fuck JS Date objects), the call center agent's timezone,
the supervisor they are talking to's timezone, and the participant they are
talking about's timezone. I hate time. I wish we would just go to a seconds-
based time system ("I'll be done with this in about a kilo-second", "I work
just under 28 kilo-seconds a day").

------
InclinedPlane
Lemme tell you about a fun little bug in the TFS Build system. You can create
build definitions, you can set the schedule for those builds. You can, for
example, schedule builds that run at a certain time of day every day (or every
weekday or every Tuesday, or whatever). That build information is then stored
in an internal representation which is actually used for scheduling. And that
internal representation, it uses UTC times. Can you see the bug here already?

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.

------
HankB99
Probably not a good time to propose decitime, I guess. (No pun intended.)

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.

~~~
dev_north_east
I can't tell if you're being serious...

~~~
HankB99
Only slightly. Changing the orbit of the earth to achieve a 333.333 day year
is not feasible b y any foreseeable technology.

------
hyeomans
Great description of pains I've been feeling the last 5 years in my daily
life. Just one comment on colors, I can read the whole post but when I switch
or look somewhere else my eyes have a hard time adjusting to all those crazy
colors I just saw. Maybe I'm broken.

~~~
jobigoud
Cone receptors saturate when you look at the same hue for a period of time and
loose sensitivity for a while. It's known as retinal fatigue or cone fatigue
and causes after images. It's normal and used in several optical illusions.

------
tlrobinson
> (My all-time fave is RFC 2606, thanks for asking! I’m in awe of that
> absolute unit. Where would we be without that banger? We’d be in complete
> fucking chaos, that’s where.)

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.

~~~
meta_AU
xip.io is one service that will wildcard for any IP address.

------
yxhuvud
That was an efficient way to heat a battery.

~~~
lucb1e
Same here. About a quarter way through the article I figured out what the hell
my system was running; then, halfway through, I had enough. I disabled
Javascript and reloaded the page. No dice. Page renders perfectly including
videos. I scrolled a little faster and skipped parts from there on.

------
sly010
Obviously it all depends on the application:

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)

------
mark-r
The Olson database is great, but I wish it included more cities. I hate having
to know the mapping from city to time zone and time zone to city. Quick,
what's the zone to use for Columbus, Ohio?

------
kstenerud
Wow... this site completely freezes my mobile browser dead in its tracks.

------
masklinn
> The Happy Monday System, which honestly I just loved based on the name of it
> alone. Shows how Japan has moved their holidays schedules around just to
> make people happier with a longer weekend.

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

~~~
madcaptenor
Independence Day, in the USA, is always celebrated on July 4. One year in
seven this creates some awkwardness: which weekend is "Fourth of July weekend"
if the 4th of July is a Wednesday?

2012:
[https://www.theatlantic.com/national/archive/2012/07/serious...](https://www.theatlantic.com/national/archive/2012/07/seriously-
how-annoying-midweek-fourth-july/326316/)

2007:
[https://www.inc.com/news/articles/200706/independence.html](https://www.inc.com/news/articles/200706/independence.html)

1990: [https://www.nytimes.com/1990/07/04/garden/and-thank-god-
it-s...](https://www.nytimes.com/1990/07/04/garden/and-thank-god-it-s-
wednesday.html) (NYT)

------
chaz6
This article covers a lot of important points, but I must nitpick one in
particular. GMT is not a timezone. Europe/London is a timezone. GMT is solar
time which is distinct from UTC as a time system. The purpose of leap seconds
is to track the difference between TAI and GMT which results in UTC (i.e. UTC
= TAI + leap seconds).

Since everything is relative, my preference for recording accurate historical
time is microseconds since TAI0. Everything else prior and future is an
estimate.

------
billysielu
I've seen a few systems mixing up their clocks, sometimes using the database
server clock, sometimes the web server clock, sometimes the user's local
clock. Whatever clock you're using, be consistent about it.

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.

------
mey
I really think we need a standard way to handle linear time that is not
effected by leap seconds but can be mapped between back to calendar time (UTC)

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.

------
axilmar
Shouldn't past datetimes be stored as nanoseconds offsets from EPOCH and
future datetimes be stored as local time?

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.

------
incompatible
"Physicists are still debating on whether or not time actually exists in the
universe."

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.

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

------
mjpuser
I would be interested to see a proposal for a standard for establishing
planetary time with the feature that you can easily convert from one planet to
the other, but I have no idea how you would do that. What happens when we move
to Mars with Elon? UTC would not be practical.

------
bkovacev
> Definitely check it out if you get really excited about reading whitepapers.
> Also get yourself checked out if that’s actually the case.

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.

------
lopmotr
A tiny bit of good news recently was North Korea getting rid of their
fraction-of-an-hour different time zone and harmonizing with South Korea.
Sadly, Australia and New Zealand are still some of the few holdouts with
stupid pointless not-on-the-hour time zones :(

------
mirimir
> UTC isn’t directly used by people (unless they’re really weird).

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.

------
LinuxBender
My current time is:

    
    
        1527698540
    

That seems easy enough for any application to deal with. Perhaps let each app
or user convert that back to their ISO 8601 of preference.

------
paulie_a
The one that has been a problem for me is comparing hourly breakdowns for DST.
How do you compare last week vs a day with 25 hours in it

~~~
holman
There's a lot of really weird edge cases like that. A lot of the times you
sort of have to make a judgement call.

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.

------
mcauser
We’re going to need a new data type: spacetime

~~~
koliber
I don't know if you were trying to make a joke or not, but you are absolutely
right! With space travel, both are needed to tell time. Things get even more
complicated quickly. Albeit, things like 15 minute timezone offsets from UTC
will become a terrestrial problem.

------
ninjakeyboard
We have had some issues with timezones and DST... Time is not fun. Funny well
written article - thanks!

------
aiCeivi9
Full screen images as a lead are the most annoying thing that can happen,
right?

Wrong:

> zachholman.com/video/utc-title.mp4

------
pleasecalllater
Could you start making websites which are readable? Jumping icons, moving
background, flickering colors, gray letters on colorful backgrounds - all that
makes me hard to read... so I'm sorry, I'm not going to read that.

------
coldacid
I thought the 12-hour thing came from Mesopotamia, not Egypt.

------
lbj
I was blown away by the design on this blog, super slick!

~~~
Washuu
Yet over here I am finding the design to be terrible, lacking good user
experience, and overall terrible to use.

------
ssijak
This is tougher to get then time in general relativity...

~~~
peterwwillis
I always figured if spacetime was relative, why don't we just report the
location we are at and that local time? If I know I was in Lower Manhattan at
2:00pm on November 19th, 2007, somebody else can just do a little math to
figure out when that actually was compared to their own local time and place.
All times are interpretive. UTC just seems like a giant hack to try to avoid
the interpretation.

~~~
quickthrower2
Who's clock is correct though.

~~~
peterwwillis
Whatever the town clock is set to.

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.

------
basicplus2
Link all back to sidereal clock time...

------
Kognito
Lost me at “rich, white railroad tycoons”. What on earth does skin colour have
to do with anything in this article?

------
nixpulvis
Elementary my dear Watson.

In all seriousness, a great collection of advice on time. Bookmarked.

------
jheriko
never worked on spacecraft then ... ;)

TAI if you can work it out :)

------
dreamcompiler
Obligatory Erik Naggum essay -- possibly his best ever:
[http://naggum.no/lugm-time.html](http://naggum.no/lugm-time.html)

------
jugg1es
This article is inspirational.

------
ATsch
The author expected this comment, but i'd still like to note that this website
saturates at least one core of my laptop, more depending where I scroll.

~~~
sp332
There are tons of autoplaying videos, and each one takes a few % of my CPU.
The biggest difference for me was the one just after the heading "Who needs
December 30, 2011 anyway".

Turning off autoplay (e.g. media.autoplay.enabled in Firefox) fixed it. You
can still play each video by right-clicking on it.

~~~
vorg
The autoplaying videos are a pain, I couldn't find "media.autoplay.enabled" in
my Preferences menu in Firefox, and this in the article calling me "clueless"
doesn't help:

> it is predictable that some clueless commenter on Hacker News will complain
> that this page has autoplaying video on it

~~~
sp332
Type about:config into the address bar and then search in there.

------
zeveb
> Base ten is lit and doing everything in twelve feels so uncivilized …

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

~~~
holman
I actually had something similar to this in my notes but didn't get around to
adding it. Basically, 60 minutes seems kind of arbitrary for an entire system
of time (at least to me!) and then I realized that once you split it down into
half, thirds, quarters, etc., it's basically the best numbers to use for
informal conversations about time. That was pretty illuminating when I read
about that; thanks for pointing it out here!

~~~
ttsda
They're called Highly Composite Numbers (or anti-primes) [1], meaning they
have more divisors than any smaller number.

[1]
[https://en.wikipedia.org/wiki/Highly_composite_number](https://en.wikipedia.org/wiki/Highly_composite_number)

------
_asummers
Typo note to author: therefor should be therefore.

~~~
rauhl
I know that ‘therefore’ is the way it’s normally spelled, but I always thought
it was goofy: all the other there-compounds (which are cognate to German’s da-
compounds) & where-compounds (cognate to German’s wo-compounds) don’t change
the spelling of their prepositions: thereafter, thereon, thereat, whereafter,
whereon, whereat &c.

I also don’t understand why modern English doesn’t take advantage of them like
modern German does.

------
lowq
11/10 - xkcd had alt text

------
quickthrower2
Sound track to accompany article:
[https://www.youtube.com/watch?v=JwYX52BP2Sk](https://www.youtube.com/watch?v=JwYX52BP2Sk)

------
blunte
Sadly I didn't have enough time to read the whole article...

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.

~~~
captaincrowbar
"You advocate a ________ approach to calendar reform..."
[https://qntm.org/calendar](https://qntm.org/calendar)

~~~
blunte
Until software is uniformly correct with respect to timezone rules and auto-
location-updating, there will be more problems with the current system than
there would be with a fixed UTC-only system.

I'll take "better" even if better != perfect.

~~~
taejo
Most people's lives don't revolve around software. Software is a tool that
shouldn't require turning people's lives upside down to work in its way.

