Sooner or later, every programmer has to deal with time zones.
And I can't really offer much advice here; I can offer a cautionary tale.
I can tell you why you really should never, ever deal with time zones if you can help it.
Let's imagine that someone has built an application
that lets you calculate how many seconds something is in the past.
You type in a date and a time, it gives you the number of seconds.
And they look at that and think "OK, that kind of works for me..."
"But let's add a little box that lets you change the time zone"
So if you're comparing between now in New York and five days ago in London, you can work that out.
And that's fine - the little drop down lets you change which hour forward or backward of Greenwich you are.
Brilliant.
Sooner or later, after it gets a bit popular, they'll get a call from Australia.
And Australia will say "G'day ma--"
-- I'm not gonna try and do accents.
I just shouldn't do accents.
Australia will say "Hello!"
"By the way, we're 9½ hours ahead of Greenwich."
And the programmer will go "really?"
"Yeah, 9½ hours."
"OK, I'll add a special case for you. That's fine."
A little bit later, someone will call from Nepal.
And they'll say "Hello. We're 5¼ hours ahead of Greenwich."
And they'll say "really?" "Yeah we've been that for ages! Yeah 5¼ hours!"
Great. Okay. And they'll put in a special case. And maybe they'll look up
the list of time zones. The Canonical list that tells you
what everything is, and they'll make sure they've covered every time zone in the world.
And then Autumn will come along.
And they'll get a call from England.
And England will say "Excuse me. Um, we're an hour out at the minute, what's going on?"
"Hold on the clock's just changed!"
"That's fine - no, we dealt with that."
"We made a note of when daylight savings changes for us, and we've put that in!"
And England will say "No, see daylight savings changes a week earlier for us."
"It's different depending on where you live."
"We shift our clocks back a week before you do."
And at that point
generally the programmer will start to hold their head in their hands
and realise what they've gotten themselves into.
And that's fine! They'll put that in
and they will deal with each country shifting to daylight savings time on a different day.
They'll look at the file that tells them how to do that and they'll copy all that in.
Then they'll get a call from someone in the southern hemisphere again who will say
"Yeah we're not shifting back in the Autumn we shift forward."
"Our spring... is in November."
At that point they'll generally start looking longingly at their intoxicant of choice
and wondering whether they should have a quick drink before keeping going...
...and they'll code that in as well.
Then they'll get a call from Samoa.
Out in the Pacific on the international date line.
And Samoa will say "Hello!"
"Yeah we skipped a day the other year."
And the programmer will say "what?"
"Yeah we skipped a day. We went from December 29th, 2011 to December 31st."
"We shifted from one side of the international date line from being hours and hours behind Greenwich ...
... to being hours and hours ahead of Greenwich. Helps us with trading with Australia."
"Can you take account of that when you work out how many days things are, and how many seconds things are in the past?"
[breathing deeply] That's fine, there's a file that tells you when any country has changed its time zone.
It turns out that that happens fairly often.
But they're announced ahead of schedule so as long as you keep that file updated
and code that into your program's logic as well, it'll be fine.
Then you look back and you notice that during World War II,
England had double British Summer Time.
It went completely onto BST and then just added an extra hour.
So it was two hours ahead of Greenwich despite... having Greenwich.
That's fine you deal with that.
Have you noticed I've started talking as if it was you or me?
Because I've done this before and it's really, really frustrating.
And you make sure you subscribe to the list
of when countries are going to change their time zones - which happens, apparently, many times!
Like, sometimes, several times in a year because governments change over.
And then this mythical programmer gets a call from Libya;
who in 2013, with only a couple of days' notice, decided that they weren't going to put the clocks back.
With enough notice that it wasn't possible for anyone to get the update out in time.
Meaning that every Libyan computer, no matter what operating system it ran...
... was an hour out.
That's OK, you read the news article about that and you hurriedly code that in as well.
And then, then you get a call from the West Bank.
Where the Israeli population is on a different time zone to the Palestinian population.
Because one is following Israel and one isn't.
Now you have two populations of people in the same location who are following different time zones.
And now they're all having to ask themselves whether they're on this time zone or this one, depending on who they are and where they are
And there's no way to code that into your program! And then...
Then you get a call from the historian.
Who says "Right, I'm trying to calculate some times back in the 18th century."
"And we changed from the Julian calendar to the Gregorian calendar."
"It's not that we lost about three weeks ...
... it's just that we skipped right from this date to this date, and missed the others."
"Can you code it so that it just kind of works that out for me?"
It's fine because someone has already told you when those dates are,
and you can code that into your program's logic as well
but now it's looking really, long and really complicated
and it's a tangled mess of spaghetti code that somehow works
and then you get a call from the Russian historian!
Who says "Yeah, we only changed to the Gregorian calendar in the 20th century ...
... and it turns out the dates you've skipped change depending on your location ...
... and can you deal with that as well?" And then you get a call from the British historian!
Who says that until, I think it was the 16th century ...
the year started on the 25th of March!
Just to blow your mind there.
From 24th of March, 924
and then it would be 25th of March, 925. And that is the next day.
Because you have gone from December 31st, 924, to January 1st, 924 because it goes in that order!
It's massively complicated, AND THEN...
You get the call from the astrophysicist...
Who says "By the way, we just had a leap second!"
And at this point, you just kind of go "... what?!"
Leap seconds; because the Earth does not rotate at a constant speed.
It slows down, it speeds up, as tectonic plates move about
and magnetic fields shift, or something like that, and so occasionally
the International Astronomical Union will work out whether we need a leap second.
If you do, the clocks go 23:59:58
and then it's 23:59:59
and then instead of going [00:00:00] like any sensible time zone would
it goes 23:59:60!
And everything breaks because suddenly you have 61 seconds in a minute!
So depending on your implementation, either ...
... your clock gets one second out of sync with the rest of the world
or it repeats a second.
The way you're meant to deal with this is with something called the Unix Timestamp.
And Numberphile, I think, has talked about this before.
That you have this number that started on the first exact second of 1970
and increments one second, per second.
Constantly. Tick. Tick. Tick.
And that's great because what you're meant to do is take whatever date has been given to you,
and you calculate that as a Unix Timestamp,
and you put that into your database.
And that'll just deal with leap seconds
EXCEPT IT DOESN'T! Of course it doesn't!
Because you have Universal Coordinated Time
which includes leap seconds!
It repeats occasionally, and it just includes 23:59:60
and then you have astronomical time! Which does not include leap seconds
and has steadily been getting out of sync with the rest of the world
because we need to look at the stars and design telescopes around it!
[deep sigh]
And what you learn...
What you learn after dealing with time zones, is that what you do ...
... is you put away your code ...
... you don't try and write anything to deal with this.
You look at the people who have been there before you.
You look at the first people, the people who have dealt with this before,
the people who have built the spaghetti code,
and you thank them very much for making it open source,
and you give them credit, and you take what they have made and you put it in your program,
and you never ever look at it again.
Because that way lies madness.
Google actually has a really, really good approach to leap seconds that they invented themselves.
There's an article about it on their blog, I think, that explains it.
They do something called a "leap smear."
Because having 61 seconds in a minute,
or because having a clock tick back a second,
can be really, really bad for massive agencies that have to
synchronise everything really precisely and have to trust that one bit of data was stored before another,
they essentially smear the second out over the whole day.
They increase their clock by a microsecond at a time.
Tick tick tick, all the way through the day.
So that it's, sometimes maybe even half a second out from reality,
but as long as everything on their servers is half a second out.
It's built to be out of sync with the world, as long as it knows that one thing happened before another.
Having continuity is more important than actually having accurate time.