Friends in need
Random Quote
Indeed, astrology is not a science at all, but merely a collection of superstitions and hokum that tries to use some of the terminology of astronomy but which rejects the logical thinking that is at the heart of science.
- Kaufmann and Freedman

Time zones - to be or not to be?

Time zones - what are they good for? And the related topic: Are there any benefits in using AM/PM and the 12-hour clock?

The widespread use of time-zones tends to add considerable complexity to an application.
[...] time handling in software, a source of confusion for many developers and content authors on the Web.

We have all been there.

It seems so easy at first, but then you start wonder. When exactly is that? It is easy when you always talk about the same time zone. But if the event is in another time zone? How do you even know if the event is in another time zone? Or if the one you should call is in another time zone? Which time zone is your destination airport in? Is it 08:25 in the morning or in the evening? How long will my flight take? Is their support open now? The time values seem so simple at first, but when you start thinking about them they become really ambiguous.

A time zone is a set of rules for determining the local observed time (wall time) as it relates to incremental time (as used in most computing systems) for a particular geographical region.

When you add information about the time zone in the list above the information become (almost) unambiguous:

But, there are still problems that need to be solved. How do you know how far apart CET/IST/UTC are from your current time zone? If I should call her 4 PM IST, what time is that in my current time zone and how do I know that? How do I even know which time zone I currently am in? When you say IST, is it Israel Standard Time or Indian Standard Time or Irish Standard Time you mean? If I currently am in the CEST time zone (daylight saving time of CET), and read the message about opening hours in the CET time zone, I start wondering if the company missed to change to CEST or if they still are using CET? By the way, when using daylight saving time, should I move the clock forward or backward?

Yes, often you have a computer, mobile phone or clock that automatically can make these calculations and conversions for you. But why? Why do we have complex rules and algorithms just to convert between times in different parts of the world? Would it not be better if we could have a simple, common and unambiguous understanding of time?

Time zone abbreviations

[Time zone abbreviations] use as sole designator for a time zone is discouraged. Such designations can be ambiguous.

The list of time zone abbrevations is looooong. And full of duplicates. So they are not useful at all, since you have to know more than just the abbreviation. It is hard to argue against that fact.

Offsets from UTC

Using offsets from UTC, for example 2017-03-25 12:34:56 +0100, is better than using time zone abbreviations. But if we want to use offsets, why not go all the way and use the UTC time everywhere instead? Then we would not have to do calculations in our heads when comparing 2017-03-25 12:34:56 +0100 against 2017-03-25 04:34:56 -0700 in order to see that these timestamps are equal. Or for that matter comparing 2017-03-24 01:00:00 +0200 against 2017-03-23 21:00:00 -0200. The timestamps in each column below actually represent the same point in time.

    2017-03-25 22:34:56 +1100          2017-03-24 09:00:00 +1000
    2017-03-25 12:34:56 +0100          2017-03-24 01:00:00 +0200
    2017-03-25 11:34:56 +0000          2017-03-23 23:00:00 +0000
    2017-03-25 04:04:56 -0730          2017-03-23 21:00:00 -0200
    2017-03-24 23:34:56 -1200          2017-03-23 13:30:00 -0930

Daylight saving time

The use of local time for time-stamping records is not recommended for time zones that implement daylight saving time because once a year there is a one-hour period when local times are ambiguous.

If I set up a meeting with you at 02:30 the morning when Sweden changes to Daylight Saving Time in the spring, should we then skip the meeting since 02:30 will never occur that morning? If we instead set up a meeting at 02:30 the morning Sweden changes back to standard time in the autumn, should we then meet twice since 02:30 will occur twice that morning? Yes, these are edge cases, but nevertheless they are real and they are confusing.

[Daylight saving times] clock shifts have the obvious disadvantage of complexity.
02:30:00 on March 30th 2014 might be a valid time, but in some timezones it is not.

The complexity of the rules for Daylight Saving Times around the different parts of our globe are ridiculous hard to understand. For example, not all countries use daylight saving time and all countries do not switch between standard time and daylight saving time at the same time. Furthermore, since daylight saving time is used in the "summer", locations in the Northern Hemisphere start to add hours to offset at the same time as the locations in the Southern Hemisphere start to remove hours from offset. As a result the time difference between two places in the world can vary during a year.

Daylight Saving Times also imply that twice a year a "day" is not 24 hours in some countries. In Sweden it will instead be one "day" consisting of 23 hours and one "day" consisting of 25 hours. In other regions a "day" will be 22.5 hours or 25.5 hours. Daylight Saving Times can therefore be confusing when talking about durations:

"PT36H" could be used as well as "P1DT12H" for representing the same duration. But keep in mind that "PT36H" is not the same as "P1DT12H" when switching from or to Daylight saving time.

Note: In the quote above, "PT36H" is a short-form for "a period of 36 hours" and "P1DT12H" is a short-form for "a period of 1 day and 12 hours".

I am not saying that we should not use daylight saving time, but we should not have to shift our clocks. Instead, we could change the working day times from 08-17 (standard time) to 07-16 (daylight saving time).

Time zone conversions

These calculations become more complicated near a daylight saving boundary.

These conversions are complex, and hence a failure.

AM/PM notation

How was it now? Was it 12 AM that indicates midnight and 12 PM that indicates midday? Or the other way around?

Are there any benefits of using AM/PM? I can't come up with any. In my opinion it is only confusing to use 1-12 AM/PM notation instead of 0-23 to describe the hour of the day and there are no mitigating circumstances.

When I read about AM/PM and 12-hour clock the text contains many words like ambiguity and confusion. So I rest my case.

Computer systems

When you see a timestamp without a time zone or offset notation (e.g. 2017-04-13 10:20:30), in an application, a web page or even in an analog paper, you start wonder if the timestamp is converted to your local time zone (as defined by your application settings, browser settings, mobile settings or computer settings) or if it is in some "standard" (read random) time zone. How should you interpret the timestamp? A timestamp without a proper notation of time zone, is that really a timestamp at all?

If you on the other hand, always would have to show the time zone or offset notations for timestamps (e.g. 2017-04-13 10:20:30 +0800), the information become cluttered.

Since the time zone used can depend on your application settings, your browser settings, mobile settings and/or your computer settings there is always a risk that you will have to look at timestamps with different time zones, depending on which application you currently is using.

Furthermore, if a person shows you a timestamp value that lacks time zone and offset notation on her computer, you must also know exactly how she has configured all her settings, otherwise you have no chance of understanding the timestamp value you are seeing.

Computer systems that need to handle time zones are (almost) guaranteed to contain errors.

Showing dates and times in a user's time zone

If you have a timestamp without a time zone or offset notation (e.g. 2017-04-13 10:20:30), you can never convert that to a specific user's time zone. In fact, that timestamp isn't a timestamp at all. The "timestamp" you have is not representing a point on the timeline, but instead an interval on the timeline, and should therefore be treated as a "local observed time" value. So trying to convert this "timestamp" value into a user's time zone will always be incorrect.

Yes, if your timestamp have a time zone or offset notation, you can convert it to a user's time zone. That is because the timestamp represents a unique point on the timeline. But, it is still a needlessly complex operation.

Times and dates in the future

Time-related things that will happen in the future are even more complex to handle, since you can't know what the time-zone rules will be in the future. The rules for a country can be altered without anyone else having anything to say about it. So the exact point on a timeline for a timestamp in the future (with respect to a specific time zone), will sometimes be moved on the timeline (or get a new "local observed time" value), if that specific time zone alters its rules.

As a rule of thumb: events that have happened in the recent past can safely be saved as UTC. Examples are timestamps for when an email has been sent or a database record has been saved. Your system knows the time in UTC and can save it in UTC. And later you can always convert it to any other time zone.

But in the case of future datetimes such as meetings: converting to UTC and saving UTC + timezone name is not resistant to changes in time zone rules. And remember, time zone rules change all the time.

Different calendar systems

Don't get me started on this one. I will just skip it for now.

Date formats

Not directly related to time zones, but nevertheless something that is really confusing: Why do we have different date (and time) formats around the world? The date values 2017-04-13, 04/13/17 and 13/04/17 can all represent the same date, depending on which part of the world you live in. If you are used to the mm/dd/yy format, how can you even know that if you see a date 01/02/03, is it January 2, 2003 in your date format or is it instead February 1, 2003 in the dd/mm/yy format you look at? It is quite a difference.

The ISO 8601 standard is a step in the right direction since:

Date and time values are ordered from the largest to smallest unit of time.

What if everyone around the world should use the same notation of time?

This is the million dollar question. Yes, most parts/people in the world, would have to rethink and make a change. But that should just take a few weeks, and thereafter it should be a walk in the park for everyone using the same time everywhere.

Note: I will use London (due to the history of Greenwich and GMT/UTC) as the starting point of a new day in my examples, but I could, of course, have chosen any place on the Earth. Perhaps the "international date line" would be a better choice.

If all of us should use the UTC time zone when talking about time, it will be no change for the people living in London. The normal workday would still be 08-17 for them. For people in Tokyo, the normal workday would instead be something like 23-08. For people in Los Angeles, the normal workday would be something like 16-01. In Stockholm 07-16, Helsinki 06-15, and so forth.

Instead of you saying that you work between 08-17, which will be confusing for everyone outside your time zone, you may say that you work 23-08, which will be unambiguous to everyone. The people in your time zone will still understand you with no effort, since their working day is also 23-08.

Dates - are they too long?

Nowadays, when we are using time zones, each date has a span of 48-hours. When January 1 starts in Wellington it will take almost 24 hours before Honolulu starts the same date. And each date, in every spot of the Earth, is 24 hours. So therefore each date spans 48 hours, since we during a period of 24+24 hours have a specific date somewhere around the globe. (In fact, it is even more than 48 hours, since the time zones around the world actually span from UTC+1400 to UTC-1200, which also implies that for an hour or two in each 24-hour period there are three consecutive dates around the globe that are all valid at the same time.)

If we instead should use the same notation of time all over the world, a specific date should be valid for 24 hours, which may make more sense.

What about days, week, weekends and holidays?

My question is: do we still really need them?


If we all should use the same time, how should we treat days? If London is the first place to enter a new day, what would that mean for Stockholm that lies ~23 hours after London? Should Stockholm also change the day/date at the same time as London? What about Wellington, that lies ~12 hours after London? If the "8 to 17" working day in Wellington should instead be 20:00-05:00, should the day/date change in the middle of a working day?

But do we really need the concept of day, when talking about times? Day, and also night, are just ambiguous definitions extremely local to every place on the Earth. If we still want to keep days, we just have to rethink that they don't always start at 00:00 and end at 23:59 in most places.

Week and weekends

Is the concept of Monday to Sunday, weekends normally being Saturday to Sunday and Monday to Friday being treated as "working days" still something we need?


Holidays, for example Christmas, Easter and Midsummer are often celebrated due to different cultures and religions and what we celebrate around the globe varies a lot. If we still want to celebrate these, we can of course keep doing that.

When should a New Year be celebrated?

A new year should of course be entered when London goes from December 31 23:59:59 to January 1 00:00:00. The big celebration would be this second, but other celebrations around the globe could be adjusted to other times in the following 24 hours.


Yes, the world would, in my humble opinion, be a better place if we stop using different time zones around the globe and instead start using the same time (without any time zone notation) all over the world! We should also get rid of the ambiguous 12-hour clock together with the superfluous AM/PM notation! Complexity, confusion, ambiguity, problems and errors are some of the most common words you see when reading about time zones and 12-hour clock. Instead of struggling with these problems, why not get rid of them, once and for all?

We have come so far nowadays, that when we talk about time, there should not be any confusion involved. There should not be any translation/conversion problems at all. When I give you a time value, you should directly understand exactly when that is, without doing any calculations. Don't make me think!

The complexities and errors related to time zone problems in computer systems will be gone and the immense cost of maintaining these systems will be heavily reduced. There will not be any confusion about whether or not a time value should be interpreted as "local time", since all time values will be universal.

The only "problem" remaining should be that some people would have to learn to go to work at another time of day, but for me that is not a problem, just an opportunity. Which complexities in life do you think that our coming generations should have to live with?

The Earth is global and worldwide. Why do we still using and handling time in the same way as we did in the 19th century?

Note: If you have spotted any errors in my calculations/conversions above, those are just additional arguments in proving my point about time zones (but of course I will be thankful if you inform me about the errors).

Additional quotes

Working with time-related data can be complex because values are related to calendars and timekeeping rules, which themselves may be somewhat arcane. One of these complexities in working with time-related data is the effect of time zone on the data.
Computer systems tell time differently than people do. So it is helpful to understand how time works within computers as well as in the real world in order to get a handle on the things that can go wrong.
Date and time values based on incremental time are time-zone-independent, since at any given moment it is the same time in UTC everywhere.
Since floating time values are often dates without any associated hours, minutes, or seconds, the resulting incremental time for these fields is often set to zero, exacerbating the problem: all time zones west of the prime meridian will consider a floating time to be the previous day.
Content and query authors are warned that comparing or processing dateTime values with and without time offsets may produce odd results and such processing should be avoided whenever possible. Generating content that omits zone offset information (where it exists) is a recipe for errors later.
If no UTC relation information is given with a time representation, the time is assumed to be in local time. While it may be safe to assume local time when communicating in the same time zone, it is ambiguous when used in communicating across different time zones. Even within a single geographic time zone, some local times will be ambiguous if the region observes daylight saving time.
The following times all refer to the same moment: "18:30Z", "22:30+04", "1130−0700", and "15:00−03:30".
A lot of technology today seems to ignore the complexities of world time, timezones and daylight savings.
There are many horror storries (sic!) of wasted time and money, hard to find bugs and “but it works on my machine”-type situations that could have been avoided if the programmers simply stopped asking the server for its “local time”.

Something similar

To get a grasp of how hard and complex time zone conversions are, we can make a comparison with the problems encountered converting between metric and imperial units.

The assignment

Say, for example, that we occasionally must convert between meters (m) and yards (yd). 1 yd equals 0.9144 m. This conversion will always be the same, since the relation is always 1 vs 0.9144. Though this conversion is rather annoying to have to do, it is still easy.

The intellectual experiment

Now consider, that a country change the relation between yd and m. So, for example, from April 4, the relation should instead be 1 vs 0.9182 and October 27 the country change the relation back to 1 vs 0.9144.

Further consider, that different countries change the relation on different dates (some countries will not change the relation at all). Furthermore, different countries change the relation differently, defined by complex rules. Some country will change the relation to 1 vs 0.9167 and some other will change to 1 vs 0.9194.

It is getting hard to follow, but we still have some more complexity to add.

Now imagine that a country change the relation between different areas within the country. For example, the United States change the relation to 1 vs 0.9156 in some state and to 1 vs 0.9178 in another state.

Furthermore, the dates that the relation changes will occur in every place of the world, will of course be different from year to year. So the country changing the relation April 4 and October 27 will use some completely different dates the next year.

Now it is time for you to do the simple math. On a random day of the year, convert 25 m defined in Stockholm (Sweden) to the correct number of yards in New York (United States). Now you are starting to get a grasp of the complexity with time zones.



World Wide Web Consortium (W3C)

Java API

MDN (Mozilla Developer Network)


And now to something completely different

The reason to why we decided to have a year of 365 days is due to the Earth orbiting around the Sun. But the reasons to why we decided to divide the year in 12 months with 28-31 days per month and why we decided that a day should be 24 hours, with 60 minutes per hour and 60 seconds per minute are not so simple to understand or agree with.

But these will be completely different discussions...

First published by Anders Gustafson 2017-04-13