WEBVTT
Kind: captions
Language: en-GB

1
00:00:00.240 --> 00:00:05.959
In computing, there's a concept called Unix
time. It's the number of seconds since January

2
00:00:05.959 --> 00:00:11.679
1, 1970. Loads of programmers use it, because
it's really easy to deal with: it means that

3
00:00:11.679 --> 00:00:15.730
instead of having all these messy months with
different numbers of days in each of them,

4
00:00:15.730 --> 00:00:19.420
and this weird thing where February has an
extra day every four years, except when it

5
00:00:19.420 --> 00:00:23.679
doesn't -- you're dealing with just one number.
The bigger the number, the later something

6
00:00:23.679 --> 00:00:24.859
happened. Easy.

7
00:00:24.859 --> 00:00:28.740
As you might know, there is a leap second
tonight as I record this, because the Earth's

8
00:00:28.740 --> 00:00:33.130
orbit is slightly irregular. And that's a
problem. Because there are two ways that Unix

9
00:00:33.130 --> 00:00:37.250
time could deal with leap seconds, and both
of them suck.

10
00:00:37.250 --> 00:00:43.540
Option 1: include leap seconds. Unix time
just keeps ticking on. That's not bad in theory,

11
00:00:43.540 --> 00:00:47.980
but in practice it means that any implementation
of Unix time that converts between it and

12
00:00:47.980 --> 00:00:53.420
human-readable time needs a database of every
leap second that's ever happened, and an update

13
00:00:53.420 --> 00:00:58.230
whenever the decision to add or remove a leap
second is taken. Otherwise when you say "6pm",

14
00:00:58.230 --> 00:01:02.320
an old system that's missed leap second updates
might understand that as a few seconds away

15
00:01:02.320 --> 00:01:06.929
from 6pm. Not important for most of the world,
but kind of important if you're working out

16
00:01:06.929 --> 00:01:12.030
the timing for, I don't know, docking a satellite.
And good luck getting that vital leap second

17
00:01:12.030 --> 00:01:15.749
update to the satellite you've already put
in space, or to the secure system that's cut

18
00:01:15.749 --> 00:01:17.380
off from the outside world.

19
00:01:17.380 --> 00:01:22.740
Okay, so including leap seconds sucks. But
not including them -- which is the second

20
00:01:22.740 --> 00:01:28.579
option, and the one that we as a species went
for -- also sucks. It means that Unix time

21
00:01:28.579 --> 00:01:33.819
isn't really the number of seconds since January
1, 1970, it's just a number you can calculate

22
00:01:33.819 --> 00:01:39.849
from whatever's on our human clocks. And because
tonight, 23:59:59 is going to happen twice

23
00:01:39.849 --> 00:01:45.609
-- officially, it's 23:59:60, but good luck
getting that through any computer system -- 23:59:59

24
00:01:45.609 --> 00:01:51.639
is going to happen twice -- that means that
Unix time is going to repeat a second.

25
00:01:51.639 --> 00:01:57.380
The key advantage of Unix time, that a bigger
number always means later? Not for those two

26
00:01:57.380 --> 00:02:01.909
seconds. And that's such a weird edge case
that it's going to cause some minor glitches

27
00:02:01.909 --> 00:02:07.670
somewhere. How? No idea yet. Why? No idea
yet. Could be something as simple as a process

28
00:02:07.670 --> 00:02:11.650
that's meant to run once a second, that would
save a file out with the current timestamp

29
00:02:11.650 --> 00:02:15.920
as its name -- it's bad design, but an easy
mistake to make. That program will discover

30
00:02:15.920 --> 00:02:20.860
there's already a file with that name, and
if it's badly designed, it will crash. That's

31
00:02:20.860 --> 00:02:25.010
a really simple bug, any actual problems will
be massively more complicated and subtle than

32
00:02:25.010 --> 00:02:28.610
that. Don't don't worry about your desktop
computer and your phone: you can set the clock

33
00:02:28.610 --> 00:02:31.660
forward and back months on those and it probably
won't mess anything up.

34
00:02:31.660 --> 00:02:37.180
Google's got a really clever solution -- a
leap smear, which steadily stretches out the

35
00:02:37.180 --> 00:02:41.430
second over the course of the day. Yes, the
clocks will be inaccurate by up to half a

36
00:02:41.430 --> 00:02:46.070
second, but their priority is making sure
that time is linear, the accuracy doesn't

37
00:02:46.070 --> 00:02:50.190
matter so much. And some stock markets are
taking a much more pragmatic approach: they're

38
00:02:50.190 --> 00:02:54.950
shutting down for the hour around the leap
second, just in case. Because in a world where

39
00:02:54.950 --> 00:03:00.620
high-frequency trading is dealing in milliseconds,
a sudden glitch in time can really mess things up.

40
00:03:02.540 --> 00:03:05.160
[Translating these subtitles? Add your name here!]