At present the world is partitioned into a finite number of large, discrete time zones. A time zone is an area on Earth where all of the clocks are set to the same time. An example of a time zone is America/Santiago, an area which covers continental Chile. All the clocks in this area are normally set to UTC-04:00. During local summer (~September to ~April), clocks are simultaneously set forward one hour to UTC-03:00, and continue to agree. Here, UTC (Coordinated Universal Time) is a highly accurate, uniform time standard realised using atomic clocks.
In general, time zone offsets are chosen so that local time roughly agrees with solar time in that time zone. For example, when local clocks say 12:00, the Sun is at or near its zenith.
With continuous time zones, local time is instead derived directly from the position of the Sun, as captured using, for example, a sundial. This is called apparent solar time. Local 12:00 is precisely when the Sun is at its zenith. Exactly when this appears to happen is subjective and depends principally on one's longitude. In effect, this divides the Earth's surface up into an uncountably infinite number of infinitesimally wide, one-dimensional, linear time zones, each running from the North Pole to the South Pole. (Or rather, from the place where the Earth's axis of rotation exits through the Arctic to the place where it exits through the Antarctic. These are not the same as 90°N and 90°S; the disagreement amounts to several metres, and varies continually.)
Got it?
It's an amazing idea! Let's look at some of the consequences which arise from this proposed change.
Solar days can run up to 30 seconds longer or 20 seconds shorter than a standard day of 86,400 SI seconds. (Note: this is not the same thing as seasons.) Variable-length days would entail variable-length hours, minutes and seconds. Although this would enable us to scrap leap seconds, it would introduce a whole host of new problems. Accurate date/time arithmetic would become extremely frustrating. Clocks would either need to tick at constantly varying rates, or be adjusted at least daily to stay accurate. Note: an incredibly significant proportion of all clocks are mechanical, or are as hard-wired in their behaviour as to make no difference; these clocks cannot be reprogrammed to tick at varying rates.
To avoid these problems, we would have to abandon strict sundial-based timekeeping (boo!) in favour of mean solar time (UT1), which corrects for these variations to yield solar days of nearly constant length.
Unfortunately, mean solar time
is impossible to track to the same degree of accuracy as any atomic time standard, and
is measured from real, whirling celestial objects, and so has that sought-after analogue warmth.
What I mean by this is that mean solar time is still variable to a significance which actually matters, even for moderately accurate timekeeping purposes. Furthermore, these variations are not predictable in advance. This means that
they would have to be announced live somehow,
date arithmetic would become even more annoying, and
UT1 could not be used for the accurate coordination of future events.
These points are all undesirable enough that we would probably not use UT1 directly either. Instead we would continue to use the atomic time standard UTC as the basis for local time. All that would really change is how we compute offsets.
With discrete time zones, the offset for any given clock is determined by referring to local law and custom. With continuous time zones, we convert the clock's physical position, specifically its longitude, to an offset from the prime meridian in hours, minutes and seconds.
Well, something like that. Remember that the International Date Line is crooked. The Line Islands sit around 150°W. Naively, this gives an offset of UTC-10:00 or so, but guess what, they're on UTC+14:00 or so, the better to do trade with the western Pacific Rim. Moving to continuous time zones hasn't changed this. Take care!
Furthermore, the International Date Line still exists. So, time zones under the "continuous time zones" system are not strictly continuous; there still remains this one discontinuity. (For truly continuous time zones, you might consider simply using the same time zone all over the world.)
When interpreted in the strictest way, continuous time zones have some pretty insane consequences.
At the equator, the position directly underneath the mean Sun travels west at about 463 metres per second. That means a standard rack unit is about one millisecond wide. At latitudes closer to the poles, the effect is amplified, although but not by more than an order of magnitude in the realistically habitable parts of the world.
So, strictly speaking, continuous time zones mean that clocks on machines in different parts of the same data centre — neighbouring racks, even — will need to be set to different times, depending on the exact positions of those racks. It means that the point location of the "clock" component within the physical chunk of hardware containing it suddenly becomes highly significant. Arguably, the time on one side of a centimetre-wide microchip should disagree with the time on the other side of it by something of the order of microseconds. Arguably, nanosecond-level local timestamps in transit east or west across the processor die should distort value while in transit, à la special relativity!
Obviously, this is nonsensical. In practice, local time would be considered uniform across any single chip and probably across any single machine. Some arbitrary reference point located somewhere in the interior of the machine would have to be nominated to serve as the machine's "official" location for the purposes of timekeeping.
We might even consider applying this consistency across all machines in any given data centre. This would simplify tasks such as e.g. collating accurately timestamped log entries from multiple machines. We would ignore the real longitudes of the various machines and set all of their clocks to the same local time. The interior of the facility would become an area of uniform time; a "time zone", as it were.
Hmmm.
This is already a problem with discrete time zones, in fact. Although very few data centres at the time of writing have a time zone boundary running down the middle of them, it is often necessary to synchronise events from geographically dispersed machines. A better solution still is to simply ignore offsets and convert all times to UTC before doing anything with them.
But continuous time zones would still find use on human-facing clocks, so let's examine those next.
In order to set a clock to display the correct time, you need to know what time zone it's in. With discrete time zones this is a matter of referring to local law and custom. With continuous time zones, you need to know the precise longitude of the clock.
In fact, you need to know the precise longitude of two clocks; the one you are setting, and the one against which you are setting it. In extreme cases, that other "clock" may be a fountain of captured, vibrating caesium atoms, but the basic principle is the same. You then need to convert the longitude difference to a time offset and set your clock's time to be the reference clock's time plus the offset.
Provided that the reference clock is within 27.8 kilometres west or east of yours, this offset will be less than one minute. If it's within 463 metres, the correction is less than one second. Again, these are the figures at the equator. At latitudes further from the equator, the margins of error shrink by a factor of at most ten. In any case, this means the correction may be small enough to ignore.
However, if your clock is being set electronically from a more distant reference clock, the reference clock may be an unknown distance away. And although the reference clock's longitude may be public (most likely it will be set to UTC, so 0°), it will not be able to tell you anything about your own clock's longitude.
These days, the easiest way to determine longitude is to use a GPS receiver. Everybody has a smartphone, right?
Well, no. It is 2017 and no, unless your definition of "everybody" is depressingly narrow and exclusionist, most people do not have smartphones.
Even among those carrying smartphones, this solution doesn't work if your clock is indoors, underground, shielded by large buildings or for whatever other reason lacks line-of-sight with GPS satellites.
So, that's a new annoyance.
Slightly more annoying is when the clock to be set is mobile.
A clock, once set, must be adjusted whenever it crosses a time zone boundary. With discrete time zones these occasions are discrete and typically fairly infrequent. With continuous time zones, local time changes continuously as you move east or west, and any clocks you are carrying must be continuously altered. The correction is one minute for every 27.8 kilometres travelled west or east at the equator, more at higher latitudes. This affects even quite short journeys, and for many people it will affect daily commutes.
If your clock is mechanical, this is a just plain unsolvable problem. You just have to adjust your clock every few kilometres, manually, forever. Or just leave it to be wrong. A conventional digital watch, likewise.
Smartphones — i.e. clocks attached to GPS receivers — will have a better chance, but still succumb to the problem of maintaining line-of-sight to the satellites. Consider a commute taken by subway train, for example.
It should further be noted that under ideal circumstances, when your clock does correctly reflect continuous time zones, time will appear to run noticeably faster when you head east and slower when you head west. On westbound plane journeys, it may even run backwards.
Several times now, I have mentioned that the effects of continuous time zones become more pronounced at higher or lower latitudes.
At the poles, it actually becomes ridiculous. Here, clocks just metres apart from one another may lie in time zones which differ by hours, and the Sun can be outpaced on foot. This causes all kinds of organisational impracticalities. At the poles themselves, time is indeterminate.
But simultaneously, the solar day itself becomes kind of irrelevant in these extreme regions. Consequently, people at, for example, McMurdo Station in Antarctica use the same local time as their supply base in Christchurch, New Zealand. Under continuous time zones, this would probably continue.
Coordinating events becomes extremely difficult. Let's take an example of television broadcasting.
It's very easy to announce that a show will begin at 21:00, but this information is useless unless a longitude is also provided, so that viewers can perform the appropriate calculations at home and know when, according to their local clock, they need to tune in. It isn't possible to announce a different time to every single viewer.
Exactly which longitude ought to accompany the announcement is up for debate. This is somewhat arbitrary, since a television show frequently has no well-defined "location" associated with it. It would probably be convenient if all broadcasts on the same channel were timed according to the same local time, though, so that shows originating from slightly different places in the world don't appear to overlap or have gaps between them.
Even ignoring the needs of viewers, the use of a fixed internal time zone is certainly necessary so that the broadcaster itself can coordinate broadcasts properly.
In fact, it would be convenient if all channels used the same local time.
Another problematic case is working out travel times.
At 07:45 a train leaves Alphonse bound for Berryway, 160 kilometres away. The train travels at an average speed of 60 kilometres per hour. What time does it arrive?
With discrete time zones, elapsed time equals distance divided by speed. That's 160 kilometres divided by 60 kilometres per hour, which is 2 hours 40 minutes. 07:45 plus 02:40 gives an arrival time of 10:25.
With continuous time zones, the first part of the calculation does still hold. A journey over a distance of 160 kilometres at an average speed of 60 kilometres per hour gives a transit time of 2 hours 40 minutes.
This gives us no information whatsoever about what the time of arrival in Berryway will be.
The original question, as stated, glossed over some important pieces of information.
When we were asked for the time of arrival, it was safe to assume that we were being asked for the time of arrival according to local clocks in Berryway.
We probably also made the assumption that 07:45 was the time of departure according to local clocks in Alphonse.
And we assumed that Alphonse and Berryway are in the same time zone, or at least that their clocks are set to the same time. This is arguably a dangerous assumption to make, but it is a logical one in most cases. Discrete time zones are generally fairly large areas, and the discontinuities in local time which occur when one steps from one time zone to the next are themselves discrete, generally relatively rare events. Without further clarification, it is reasonable to assume that this entire scenario takes place in a single time zone, otherwise additional information would have been given.
With continuous time zones, the third assumption falls out from under us. We can never make this assumption about a journey, even for the purposes of a mathematics problem, because thanks to simple general knowledge we know that to a first approximation every journey crosses time zones. Plane journeys cross time zones, train journeys cross time zones. Walking the dog crosses time zones! The only journey which doesn't cross time zones is one which proceeds directly north or south along a line of longitude, and these are vanishly rare. This renders the problem, as stated, unsolvable. We can say with some certainty that the train will arrive at Berryway at 10:25 Alphonse time, but what use is that?
We need longitudes.
Let's say Alphonse is at 0°7'39"W. Berryway is at longitude 2°21'2"88E.
This extra information enables the problem to be solved with a little extra arithmetic. The difference in longitude is 2°21'02"88 - (-0°07'39"00) = 2°28'41"88 = 2.4783°. This means that time in Berryway is 2.4783° / 360° * 24 hours = 9 minutes 54.792 seconds ahead of time in Alphonse. Arrival time, then, is 10:25 plus this offset, which is 10:34:54.792.
Whew.
So, elementary travel calculations are now maddeningly difficult. Every single time-and-distance calculation now requires twice as much information to be even solvable, and twice as much calculation to actually solve. Mental arithmetic, for this previously trivial sort of problem, is now, if not dead, at least highly niche.
Timetables, too, now become twice as complicated as they already were. It is simply not possible to publish minute-accurate timetables without taking relative longitude corrections into account, which means it is not possible to express both arrival/departure times and journey duration using a single pair of times.
This was already an annoyance with plane travel, but now it becomes a problem with literally every timetable for every form of transport. This also introduces difficulties for the transport operators themselves, difficulties which can very easily introduce errors.
Fatal rail crashes, even. This isn't even a hypothetical. Railway time, a standard time zone for the whole railway, was first introduced specifically to resolve the problems of stations all using subtly different local times. Under continuous time zones, railway time would certainly need to be reintroduced.
And a couple of other minor annoyances:
Zoneinfo, the time zone database which was formerly the solution to most problems involving discrete time zones, would probably require some serious restructuring, as would all of the diverse computer systems which consume its data.
Leap seconds still exist. And it's not remotely clear what happens during a leap second when one's time zone is not a round number of minutes. Perhaps instead of truly continuous time zones, we could use 1440 very narrow, one-minute-wide time zones?
Wait, more than 1440. The Line Islands, remember?
With continuous time zones:
And what would happen after a few years of this? People would start voluntarily setting their clocks to times which agree with one another. Maybe by local custom, maybe by local law. Eventually, everybody would lock in on railway time as their standard time zone.
And continuous time zones would edit themselves out of existence. And we would arrive back at discrete time zones. Again.
This is a really bad idea, and thankfully only a relatively small number of people have been known to seriously propose it. Still, it makes a fun thought experiment.
The sad, ultimate truth of modern timekeeping is this: it's not perfect, but it doesn't honestly get a whole lot better.
There are improvements we could make. But the improvements are marginal, and they would be tremendously expensive. We're at a local optimum now. The best we can say is that our flawed system is at least a system whose flaws we fully understand.
Nevertheless, here as in all aspects of all our lives: it is critically important to keep reflecting.
Discussion (23)
2017-03-11 02:55:46 by qntm:
2017-03-11 04:00:03 by R. James Gauvreau:
2017-03-11 04:44:03 by Ulyssessword:
2017-03-11 04:58:14 by Nathan:
2017-03-12 13:18:35 by TheTrueMikeBrown:
2017-03-13 07:42:41 by cnte:
2017-03-13 17:16:43 by P:
2017-03-15 09:22:18 by Jymbob:
2017-03-25 04:33:50 by Michael:
2017-03-31 02:47:27 by Daniel H:
2017-03-31 02:49:04 by Daniel H:
2017-04-11 19:04:52 by Billy:
2017-04-12 01:19:22 by frozenLake:
2017-06-18 05:17:21 by Daniel H:
2017-06-18 05:19:07 by Daniel H:
2017-09-02 23:32:08 by asdf:
2017-11-03 20:31:11 by Baughn:
2017-11-13 15:10:21 by Tahrey:
2021-04-09 16:31:02 by Aluicious:
2022-03-16 17:56:12 by norse:
2022-03-17 01:00:11 by Christopher Jones:
2022-03-21 23:14:28 by crs:
2022-03-24 08:14:59 by Marek: