Friends in need
Random Quote
Programs must be written for people to read, and only incidentally for machines to execute.
- Hal Abelson and Jerry Sussman

Time zones - to be or not to be?

Time zones - what are they good for? And the related topics: Are there any benefits in using AM/PM and the 12-hour clock? Why do we have several different date formats? Can you tell me what time it is?

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.

Even answering a simple question like "What time is it?" is sometimes impossible.

Trying to avoid ambiguity

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 to the list above the information become less ambiguous:

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?

And by the way, how do you easily know if your computer, mobile phone or clock has switched to the new time zone or if it still shows the time in the old time zone? How can you trust the time value that you see on these devices? How can you unambiguously know if the time you see is the correct time for the location on Earth where you are at the moment?

If you fly between Stockholm and Los Angeles and go to sleep for a few hours and then wake up and you ask your neighbour what the time is. How does she know what to respond to you? Should she tell you the current time in Stockholm? Or the current time in Los Angeles? Or is it the local time where you are at the moment that you are interested in? And how can she easily find out the answer?

Note: The above is an example of what I call the "trunk of a car" problem. Imagine you are placed in a trunk. You have a watch on your arm. The car is travelling around for many hours and you have no idea in which directions. You manage to escape. The question now is: Do you know what time it is? (Yes, what time it is may be your smallest problem in this situation, but I think you get the message.)

A real world example from a scheduled flight. Going from Perth → Singapore → Moscow → Stockholm. Starting in Perth 17:30 and landing in Singapore 22:45. Then from Singapore 00:15 and landing in Moscow 06:20. Finally from Moscow 07:35 and landing in Stockholm 07:45. All the times are local times. With this information, it should be easy for you to answer the following questions. What is the total time of the trip? What is the time for each leg?

Note: Oh, did I forget to give you the date of the flight. Sorry about that. The date is rather crucial information that you need to have if you should be able to get correct answers. That is because some of these cities use Daylight Saving Time (DST) during parts of the year. So even if you know the time zones or offsets for each of the four cities, you still need to know if DST is active.

I am in Sweden and my wall-time shows 10:00. You are in Finland and your wall-time is showing 11:00. I am on the phone with you and I say that you should call me again at 16:00. When will you call me? When your wall-time is showing 16:00 or when mine is showing 16:00? To avoid confusion, either I have to add "my time" or "your time" or I have to instead say something like "call me in six hours" or "call me in five hours".

Take a moment and think about all these complexities and difficulties.

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 abbreviations is looooooong. 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.

Time zone identifiers

The most definitive reference for identifying sets of time zone rules is the TZ database.
In the TZ database, time zones are given IDs that typically consist of a region and exemplar city. An exemplar city is a city in the time zone in question that should be well-known to people using the time zone. For example, the U.S. Pacific time zone has a TZ database ID of "America/Los_Angeles".

The list of time zone identifiers is even longer than the abbreviations list. But it is slightly more useful, since there at least are no duplicates. Using the TZ database seems to be extremely complex though and you need to keep yourself updated to the never ending changes. And you rarely see times defined using the identifiers (for example 2018-01-27 14:30 CET is far more common than 2018-01-27 14:30 Europe/Stockholm).

By just using your own brain, do you know what the current time difference is between the capital cities Canberra in Australia ("Australia/Canberra") and Buenos Aires in Argentina ("America/Argentina/Buenos_Aires")?

Offsets from UTC

Using offsets from UTC, for example 2017-03-25T12:34:56+0100, is much better than using time zone abbreviations (and perhaps even better than using time zone identifiers). 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-25T12:34:56+0100 against 2017-03-25T04:34:56-0700 in order to see that these timestamps are equal. Or for that matter comparing 2017-03-24T01:00:00+0200 against 2017-03-23T21:00:00-0200. All the following timestamps actually represent the exact same point in time.


Note: I have used the ISO 8601 format for timestamps in this text, since that is the least error-prone notation the world has come up with so far.

Number of ideal time zones

Since the time zones around the globe should be one hour "long" each zone should span 15 degrees longitude (15° × 24 = 360°). So you may think that there are 24 offsets spanning 15 degrees each. But, in fact there are 25 time zones for exact one lap around the globe (UTC+1200, UTC+1100, ..., UTC+0100, UTC+0000, UTC-0100, ..., UTC-1100 and UTC-1200). So in order to get the math working, UTC+1200 and UTC-1200 span only 7.5 degrees each.

Note: 25 time zones is for one lap and with whole hours. As you will see later on in this text, there are far more than 25 time zones, since they span more than one lap and since there (sadly) are many time zones with offsets of 15 and 30 minutes.

Daylight saving time (DST)

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.

Absurd complexity

[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. Within some countries the switches are not performed simultaneously.

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 (and as an example, can be two, three or four hours, depending on which time of year it is). Let us take Canberra in Australia (UTC+1000 (as standard)) and Stockholm in Sweden (UTC+0100 (as standard)) as an example. We have the following timestamps for some random dates during 2017:

    Canberra                    Stockholm
    2017-03-25T20:00+1100  10h  2017-03-25T10:00+0100
    2017-03-26T20:00+1100   9h  2017-03-26T11:00+0200
    2017-04-03T20:00+1000   8h  2017-04-03T12:00+0200
    2017-09-30T20:00+1000   8h  2017-09-30T12:00+0200
    2017-10-02T20:00+1100   9h  2017-10-02T11:00+0200
    2017-10-30T20:00+1100  10h  2017-10-30T10:00+0100

Hours in a day

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. Most of the countries add one hour when using DST, but in some places 30 minutes is added. So a "day" may also be 23.5 hours or 24.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".

Time switches due to DST

Thanks to the use of daylight saving time in some of the time zones, we have about 60 distinct occasions per year when a location/area/zone is changing its relation to all the other locations/areas/zones around the world. The total number of time zone identifiers that use DST each year is about 200, so there is roughly 400 switches in total.

Note: Of course, the number of switches to/from DST varies from year to year, since countries can not decide if they should use DST or not and may change there minds. The relation between 60 and 400 is that some time zone identifiers switch to/from DST simultaneously (for example large parts of Europe).

Several DST switches in the same year

Sometimes, things are complicated even more, when for example religion is mixed in to the time keeping.

Summary for DST

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.

Noon and solar noon

One of the reasons to have time zones, is that no matter where you live on the Earth, when your clock is 12:00 (noon) the Sun would be at its highest altitude in the sky (solar noon).

But, since each time zone (often) spans 15 degrees this will not be completely true for most of the places on Earth and therefore nothing you can rely on. The solar noon, for most places, will instead be somewhere in the span 11:30 to 12:30. For some places though, for example in Spain and China, the solar noon will be way outside this one-hour interval.

Celebrating a new year

The administration of when a specific place on Earth will enter a new year is tremendously error prone. Every year when media shall make lists of countdown times to the new year for different places the lists contain errors. So you can not rely on the lists without double checking them.

The fact that, every new year, there are more than 30 occasions/points on the time-line that represent a "new year" is hard to understand.

Problems within large countries

I will show some examples of existing problems for some large countries. Either when the country has decided to use several time zones or when the country has refused to use several time zones.

Countries with several time zones

Some countries use many different time zones. The complexity of these solutions vary from country to country.


Australia has five different (standard) time zones (or perhaps it is just three). These are UTC+0800, UTC+0845, UTC+0930, UTC+1000 and UTC+1030.

There are also a couple of places in Australia, that use separate times than the states/territories they lie in.

Furthermore, some of the states/territories use Daylight Saving Time, but not all. For some of the time zones the DST is one hour and for at least one time zone the DST is 30 minutes.

Australia has multiple time zones. Some of them are half-hour and quarter-hour time zones. Not all states and territories use DST.

How the people in Australia know what the time difference is between two random places in their own country on a random date is an unsolved mystery to me.

United States of America

United States of America has nine different time zones. Or is it eleven? Of course not all of the time zones in US use Daylight Saving Time and to make things even worse the states do not even switch to and from DST simultaneously. The state Arizona is a remarkable example in how things can go wrong with DST.

If we take the three cities Chicago (UTC-0600), Los Angeles (UTC-0800) and Honolulu (UTC-1000) as an example, we have the following interesting table for the latest switch to DST, 2017-05-12, where there is exactly one hour on the timeline between each row:

    Chicago            Los Angeles        Honolulu
    01:59:59-0600  2h  23:59:59-0800  2h  21:59:59-1000
    03:59:59-0500  3h  00:59:59-0800  2h  22:59:59-1000
    04:59:59-0500  3h  01:59:59-0800  2h  23:59:59-1000
    05:59:59-0500  2h  03:59:59-0700  3h  00:59:59-1000
    06:59:59-0500  2h  04:59:59-0700  3h  01:59:59-1000
    07:59:59-0500  2h  05:59:59-0700  3h  02:59:59-1000
    08:59:59-0500  2h  06:59:59-0700  3h  03:59:59-1000

For some unclear reasons, the state Florida currently uses two time zones, CST (Central Standard Time) and EST (Eastern Standard Time). How do you know what local time to use if you are in the north-west parts of Florida?

Yes, it is also a mystery to me how the people in United States of America know what the time difference is between two random places in their own country on a random date.


Russia has eleven different time zones. At the moment they are not using Daylight Saving Time at all, which is a good decision. Even though Russia has more time zones than Australia and United States of America, it is far less complex to decide time differences within Russia than within the other two countries.

Countries with one time zone but spanning several

There are also some countries that span several time zones, but have chosen to use only one time zone for the whole country.


China is a large country from west to east and spans more than 60 degrees of longitude and therefore China could have used five time zones. Still, China uses the same time zone (UTC+0800) in the whole country.

So in the westernmost parts of China, the solar noon can be after three o'clock in the afternoon. Some of the population in these westernmost parts unofficially use UTC+0600 as their time zone, which can give some interesting conversations:

While the Uyghur population usually go by Xinjiang Time, known colloquially as “local time”, other ethnicities, like the Han Chinese, normally refer to Bejing Time. This means that visitors asking for the current time in the streets of the region's capital Ürümqi might get 2 conflicting answers, depending on whom they ask.

I do think though, that China has made a good decision with using only one time zone. And if they can, why can't we do it all around the globe...

Computer systems

When you see a timestamp without a time zone or offset notation (e.g. 2017-04-13T10: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-13T10: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.

Converting dates and times to user's time zone

A time without a timezone is as dangerous as a measurement without units.

If you have a timestamp without a time zone or offset notation (e.g. 2017-04-13T10: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 one point on the timeline, but instead several distinct points 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 and often only add confusion (as described in the Computer systems section above).

Times and dates in the future

Time-related things that will happen in the future are even more complex to handle, since you can not 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.

The Time Zone News is a depressing page to read if you want to avoid problems in the future.

Nautical time zones

And then we have the nautical time zones to make things even worse.

Unofficial time zones

In some countries (for example in Australia and China) unofficial time zones are in use in some parts of the country.

Misleading time zones

Some countries use time zones that are quite misleading. For example, Algeria and Tunisia, use the CET time zone. CET stands for Central European Time in this case, but Algeria and Tunisia are countries in Africa. Egypt, another country in Africa currently uses Eastern European Time (EET).

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 (or perhaps even February 3, 2001 in some lazy yy/mm/dd 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.

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? Why starting a new day with 12 which is the highest value in the sequence?

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.

A proposal for alteration

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 (the DST issues are ignored here for "simplicity"). So therefore each date spans 48 hours, since we during a period of 24+24 hours have a specific date somewhere around the globe.

But that is not completely true. It is more like 50 hours. Since some countries (for example Kiribati) have come up with the (not so great) idea that they want to be first entering a new date instead of being last. So, the time zones around the world actually span from UTC+1400 to UTC-1200. When we start a new date, for example January 29, in UTC+1400, we have


When we fast-forward 24 hours, there are still some time zones that have not yet entered January 29


After another 24 hours it will still be January 29 in some time zones


Two hours later we have finally passed January 29 everywhere


The invention of UTC+1400 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. So for example, the following timestamps represent the exact same point on the timeline

    2018-01-30T01:59:59+1400 (Tuesday)
    2018-01-29T23:59:59+1200 (Monday)
    2018-01-29T11:59:59+0000 (Monday)
    2018-01-28T23:59:59-1200 (Sunday)

So if you would ask three random people, what date it was when they saw a specific celestial phenomenon, you may receive three different answers, and they would all be correct.

Even if we should get rid of the strange UTC+1300 and UTC+1400 time zones, we still would have an interesting fact. Thanks to the UTC+1200 to UTC-1200 span, there always are at least two consecutive dates valid at the same time (since UTC+1200 and UTC-1200 never can be on the same date). The following timestamps represent the exact same point on the timeline


And one second later they look like this


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. I can not remember that I ever have seen a set of rules with so many exceptions as when reading about time zones. Instead of struggling with these problems, why not get rid of them, once and for all?

Daylight Saving Times are, by far, the largest and most complicated problem when talking about time zones. The time relation between locations may vary during a year. Getting rid of DST is a first step. Then we have the ambiguous and useless time zone abbreviations. Get rid of them in the next step. Next, only use time zone identifiers to identify which UTC offset to use (for example, "Europe/Stockholm" will map to UTC+0100 and all you will ever see in your timestamps are UTC+0100). At this point, since we are not using DST, and all the relations between locations are static, we never have to convert from UTC offset to a time zone identifier again. Now, the step to only use UTC+0000 would be quite trivial.

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

It is also a very interesting fact that when time values are really important not to mess up, such as with aviation, the UTC+0000 (Zulu time) is most often used, regardless of where on the Earth you are. No ambiguous offsets, time zones or local times are used, since we can not accept misunderstandings with catastrophic consequences. Why do we continue to accept misunderstandings in less critical areas?

If you should ask someone what time it is just now on a random place on Earth, I do not think that there is anyone that always can answer you correctly, without the help of some kind of computer. And even if they have help from a computer, they will most certainly be incorrect sometimes.

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 use and handle time in the same way as we did in the 19th century? What have we done to deserve this? Time zones do not improve or simplify our lives.

Moral of the story

Time zones must be destroyed.

Note: If you have spotted any errors in my calculations/conversions in the text, 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).

Note: The reason my text contains so many occurrences of the words "ambiguity", "complexity" and "confusion" (and their similar friends), is because I want to emphasize that there is so much ambiguity, complexity and confusion involved when using time zones.

Note: You could argue that the timestamp 2018-01-16T01:23:45+0800 is not a point on the timeline, but merely an interval, since the precision is only seconds. But I think it is precise enough for this text. If you lower the precision even more you can of course argue that a date 2018-01-16 or even a year 2018 is also a timestamp, and I can agree with that. Nevertheless, two important things to remember about timestamps are; (1) a time 01:23:45 without date (and offset) information can never be a timestamp, since it represents an infinite set of points on the timeline; (2) a time 2018-01-16T01:23:45 without offset information can never be a timestamp, since it represents several points on the timeline.

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”.
Australia has multiple time zones. Some of them are half-hour and quarter-hour time zones. Not all states and territories use Daylight Saving Time (DST).
Broken Hill is in New South Wales, but uses Australian Central Standard Time (ACST) which is 30 minutes behind the rest of the state.
Eucla in Western Australia is 45 minutes ahead of the rest of the state. It has its own time zone called Australian Central Western Standard Time (ACWST).
Lawmakers in Brazil have decided to move the start of Daylight Saving Time (DST) from 2018, effectively shortening the DST-period in the country by two weeks.

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



Now to something completely different

The reason 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