Logo for Nemo Nisi Mors
Friends in need
Random Quote
Testing can show the presence of errors, but not their absence.
Edsger Dijkstra
Modified 2019-09-08T10:31:53Z

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 still have several different date formats? Can you tell me what time it is?

Note: You can hide all notes, quotes and references, by the checkbox above. I do recommend you to show them all though, since they contain valuable information, interesting facts, clarifications, elaborations and explanations. The complete text, with quotes, references and notes, corresponds to about 40 A4 pages and without those it is about 25 pages.

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.
There is no way you can know from your location alone which time zone applies at some particular point on the face of the earth: you have to ask the people who live there what they have decided.
The following times all refer to the same moment: "18:30Z", "22:30+04", "1130−0700", and "15:00−03:30".

[Please, take me directly to TL;DR, or at least to the summary section with the easy step-by-step solution to all the problems]

Note: This text contains my own thorough and comprehensive compilation of the pros and cons (mostly cons to be honest) of our current timekeeping system. The first version was published in April 2017, but the content is continuously revised and updated (last in September 2019) with new insights, clarifications and examples that I have stumbled upon during my life. Hopefully, reading this will give you valuable information and enhance your knowledge about some difficulties with timekeeping.

Note: [Spoiler alert] You will find out that my answers to the four questions in the first paragraph above are: "Almost nothing", "No", "I really don't know" and "Sometimes, but far from always" respectively.


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 and clear 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.

Note: As you will see, your only chance to be correct when asked "What time is it?", may be to answer "I don't know" or start your answer with "It depends...".

Note: If you are among those that only interact with people living in your own time zone, or if you don't even know what time zones are and that there are different wall-times around the world, you can keep on living in your bubble and skip reading.
If you belong to the increasing number of people that, in one way or another (perhaps through this thing called the Internet or by travelling), interact with people all around the globe, I think it will be well worth reading further. You will never look at date and time values in the same way again though and you will have a hard time to trust your watch. So buckle up and prepare for a mind-blowing journey through time and space.

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 and ET 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? Is ET before or after my time zone, i.e. will the game be broadcasted before or after 15:30 my local time? Perhaps the game will start to broadcast 15:30 my local time, despite the fact that I am in another time zone than ET? Is ET even a correct official time zone?

Note: ET is probably a lazy and confusing way of denoting either EST or EDT.

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 be sure that your devices are using the correct rules for time zones and daylight saving times? How can you trust the time value that you see on these devices? To summarize, how can you unambiguously know if the time you see on your device is the correct time for the location on Earth where you are at the moment?

Note: If you do not see the problems, here is an example and another example of what happens out there in the real world.

Local time

Sometimes you see the times for events announced on the Internet like "Saturday 2018-10-20 19:30 local time". This leaves a big question mark in your face. Now it is up to you to investigate what this "local time" may mean. You may have no information about how many hours before or after your current time zone this "local time" is. As you will learn, it is not an easy task to solve this on your own.


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? If you are the pilot, you may in fact be asking about the current Zulu time.

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? Is it any difference if you have a mechanical watch or a high-tech computerized watch? (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 flight time for each leg?

Another example is a flight from Stockholm → Chicago → Denver. From Stockholm 10:20 and landing in Chicago 12:35. Then from Chicago 14:15 and finally landing in Denver 16:00. Total time? Flight time for each leg?

Note: Oh, did I forget to give you the date of the flights. Sorry about that. The date is mandatory information if you should be able to get correct answers. No, I am not joking, this is absolutely true. You need the date because some of these cities use Daylight Saving Time (DST) during parts of the year. So even if you (are among the few that) know the time zones or offsets for each of the cities, you still need to know if DST is active during the flight.
If I would give you the date, would it then be an easy task to answer the questions? Or do you still need to use the Internet for help?

Note: Even the time between two legs may be hard to calculate. Even if you know your arrival time and your departure time on a specific airport, you can not just take the time difference between those two local time values. There may be a DST switch during your stay at the airport.

A flight from Amsterdam to New York. Starting at 13:25 local time and arriving at 15:25 local time. What is the flight time?

Note: Once again, it is impossible to give a correct answer without the date. The answer could be either of 7, 8 or 9 hours (or something completely different), depending on what the current DST rules are for Amsterdam and New York.

Note: When I talk about date in the examples above, I mean a complete date, with year. It is not enough to say that the flights are February 4, August 23 or December 11. You must also define the year. No, I am not joking now either.

Let us take an easy example instead. You fly domestic in the US from Florida to Indiana. You depart from Florida 16:00 (local time) and it is a three hours flight. When will you arrive in Indiana (local time)?

Note: I am still not joking, but you can not give a correct answer to the question, since valuable information is missing. Even if I define the complete date, you lack information. As you will see you need detailed information about which part of Florida you leave and which part of Indiana you enter.

Summary of things to consider when flying

You take a six hours flight starting at 11:40 local time. When will it land? The answer is highly dependent on (at least) three things; (1) the direction of the flight, (2) the speed of the flight and (3) the daylight saving time rules (at both departure and destination). Think about that again. You have to know direction, speed and daylight saving time rules, in order to know when you will land. If you are flying straight north or south, you may land at 17:40 local time, regardless of your speed. If you fly to the west or east you must take your speed into account. Fast westbound flights may land before 11:40 local time or even the previous day. Fast eastbound flights may land the next day.

Note: Just because you fly straight north or south, it does not mean that you always will land 17:40 local time though, since time zones rules can be very strange (for example India vs China or Argentina vs Peru).

Note: If you cross either of the poles in a north/south flight, you will probably loose or gain about 12 hours in a blink.

Note: If you cross the International Date Line in either direction, your six hours flight will result in even stranger results in local time and local date, since if flying west you may now land the next day and if flying east you may land the previous day. So going in the same direction could in fact "travel" you back or forth in time, depending on where on Earth you are.

Note: Yes, it is speed of flight, not speed of light that I am talking about above. The speed of light, together with relativity, will certainly be a factor in a perfect timekeeping system though.

Note: Yes, in order to know the daylight saving time rules, you must of course first know the time zones at departure and destination (which is not always a trivial task to solve).


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".

It is even worse, if I am in Sweden with wall-time 23:00 and you are in the United States with wall-time 15:00. I say that you should call me again tomorrow at 14:00. If the month is March or October, we may also have to worry about if any of our countries (or to be correct, any parts of our countries) have made a transition to/from Daylight Saving Time during the night.

What if I am in Sweden with wall-time 23:00 and you are in eastern Australia with wall-time 08:00. I say that you should call me again tomorrow at 09:00. When is that? I may mean "Call me again in 10 hours", which is 09:00 tomorrow for me. But for you, 10 hours from now is still today, at 18:00. Of course, we also have the "Daylight Saving Time switch during the night" issues, so my wall-time 09:00 tomorrow may actually be 9, 10 or 11 hours away.

Note: I emphasize that if your wall-time is currently 00:00, your wall-time showing 04:00, may in fact be 3, 4 or 5 hours away. It may even be 3.5 or 4.5 hours away.

You manage an online meeting with participants all over the world. Your clock is showing 11:00. You tell the participants that you will take a break and continue at 13:00. Many will be confused about how long the break will be and when the meeting will continue. If you instead say that you will take a two hours break, everyone will easily understand when to continue.


Calm down and take a moment and think about all these complexities and difficulties.

Abbreviations, identifiers and offsets

Why do we mix abbreviations, identifiers and offsets for time zones when we want to define an exact point in time? Can we easily convert between those variants?

Note: Sadly, the answer to the second question above will be "No". Sometimes we can't convert at all. From an identifier, you can convert to both of the others, but from an abbreviation or offset you can't convert at all. But beware, you must have a complete timestamp, containing the date information, to be able to convert from an identifier, since it is not a perfect one-to-one mapping.
Take the identifier Europe/Stockholm as an example. Sometimes this identifier "equals" the abbreviation CET which is UTC+01:00. But, sometimes the identifier "equals" CEST which is UTC+02:00. It depends on what time of year the time value refers to. So you must also know if Daylight Saving Time is active or not for the particular time value.

World Time Zones Map

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. More important, the list is full of duplicates, so the abbreviations are useless, since you have to know more than just the abbreviation. It is hard to argue against that fact.

Note: How is it even possible that these abbreviations contain duplicates? When did it all go wrong?

Moreover, most people do not have a clue about what the abbreviations stand for and where on Earth they are used. Sometimes you add an extra character when DST (Daylight Saving Time) is used, sometimes you instead change a character during DST. Most abbreviations use three or four characters, but there are some with two or five characters also.

Note: For example, the standard time zone EET will be EEST during DST, but the standard time zone EST will instead be EDT during DST. You will get an extra point if you know the full names of these abbreviations and another point if you know where on the Earth they are used. Yes, you are correct, I am not a fan of abbreviations anywhere.

Note: A real advert for a livestream event on the Internet from a large tech company says: Wednesday, May 1 | 9:30 a.m. – 11 a.m. PT. When is this? If I search among the time zone abbreviations for PT I find nothing. There are both PST and PDT (and a bunch of other abbreviations beginning with P and ending with T), but no PT. So first I have to guess that PT probably stands for PST or PDT. Then I have to figure out if DST is active 2019-05-01, but then I need to know more about the actual physical location. After more searching in the advert I find that the location is San Francisco and I end up in complex pages like time offsets in US and time in US. So instead of giving an unambiguous time interval for the event, the company fails hard and leaves everything to the reader.

Note: Sometimes you see a timestamp that looks like 2010-11-12 10:11:12 (Central European Standard Time). You may then think that the time zone part is abbreviated as CEST. But no, Central European Standard Time is instead abbreviated with CET (the correct name is Central European Time). There is an abbreviation CEST though, but it stands for Central European Summer Time. So by trying to be more comprehensible by adding "Standard" the time value has instead become even more ambiguous and confusing.

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

Note: There are no duplicates in the list of time zone identifiers, but it still contains some strange values. You have some aliases, which is okay, since they are probably used for defining several different cities that in fact use the same time zone (for example "America/Montreal" that is an alias for "America/Toronto" or "Arctic/Longyearbyen" as alias for "Europe/Oslo").
But some of these aliases seem to define the same city with different identifiers (for example "America/Indianapolis" as an alias for "America/Indiana/Indianapolis" or "Asia/Ulan_Bator" as an alias for "Asia/Ulaanbaatar"). So when seeing two different time values, 2019-03-17 08:25 Asia/Ulan_Bator and 2019-03-17 08:25 Asia/Ulaanbaatar, you should interpret these as the same.
The list of time zone identifiers also contains many deprecated values.

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 Mexico City in Mexico ("America/Mexico_City")?

Note: No, I don't have a clue about the current time difference either. My best guess is about 12 hours and that the difference may vary by two hours depending on what time of the year it is (as you will see when reading about Daylight Saving Time craziness below).

Another thing with using time zone identifiers (and also abbreviations) is that you lay the burden on the receiver of the message to interpret what time it represents. Instead of you defining an unambiguous time value for everyone, you are lazy and may make many people around the globe confused.

Offsets from UTC

Using offsets from UTC, for example 2017-03-25T12:34:56+01:00, 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+01:00 against 2017-03-25T04:34:56-07:00 in order to see that these timestamps are equal. Or for that matter comparing 2017-03-24T01:00:00+02:00 against 2017-03-23T21:00:00-02:00. All the following timestamps actually represent the exact same point in time.


That was not completely true, there is one timestamp above that is not equal to the others. Did you spot it? It should be easy to see it, since this is basic time keeping knowledge.

Note: No, it is not 2017-03-24T23:34:56-12:00, 2017-03-25T21:04:56+09:30 or 2017-03-25T17:19:56+05:45 that is unequal. It is 2017-03-25T08:34:56-04:00 that represents a time that is an hour before all of the others.

Note: I have used the ISO 8601 extended format for most 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 "wide", 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 (roughly about 40), since they span more than one lap and since there (sadly) are many time zones with offsets of 30 and 45 minutes. Of course, the actual number of time zones used is far, far more than 40 as you saw in the abbreviations and identifiers sections above.
Of course, this implies that a "timestamp" like 2019-04-18 09:15 will occur at about 40 different occasions.

Note: Yes, the UTC+1200 and UTC-1200 zones span actually 15 degrees each, but that is because they are "overlapping". In fact they represent the same "zone", so the local time is equal, but the dates are exactly one day apart.
This also implies that two persons in this part of the world may agree on the current local time, but at the same time they may disagree on the current local date.

Deciding correct offset from location

From your physical location on the Earth, it is sometimes impossible to know which offset or time zone you should use. Even if you know your exact longitude and latitude coordinates, there is no perfect tool that will inform you about the correct offset.

Straight line travelers

Some of the ideas with time zones are that (1) when you travel east, your local time increases when you cross a time zone border and (2) when you travel west your local time decreases when you cross a time zone border. When you travel north or south your local time should stay the same. The reason behind this is that the local time should stay in "sync" with the solar noon. But there are several examples of really strange results around the world and I will show you some of these.

Note: Yes, if daylight saving time is active in any of these countries during your travel, the result will, most certainly, be different.

West-east travelers

In theory, when traveling west-east your local time should make a one-hour jump, every 15 degrees.

The 69th latitude

If you travel the line from coordinate 69.04 (lat), 20.00 (long) to coordinate 69.04 (lat), 30.00 (long) you are traveling a distance of 10 degrees longitude (roughly 400 km at this latitude). This is about 2/3 of an ideal time zone, so the time difference would be approximately 40 minutes between your start and end points. Your start point is located in Norway and your end point in Russia, as you can see in NNM Map Viewer.

If you write down the offsets from UTC during your travel you get interesting results. You will cross the following country borders from west to east: Norway, Sweden, Finland, Norway, Finland, Norway, Finland, Russia, Norway, Russia. The standard time zone for Norway and Sweden is UTC+1, for Finland it is UTC+2 and for this part of Russia it is UTC+3. Since Norway and Sweden (at the moment) use the same UTC offset, you will have the following nine(!) time zones during your trip: UTC+1, UTC+2, UTC+1, UTC+2, UTC+1, UTC+2, UTC+3, UTC+1, UTC+3. Sometimes the difference is one hour, but in the two last switches the difference is two hours.

North-south travelers

In theory, when traveling north-south your local time should always stay the same.

The 27th longitude

If you travel the line from coordinate 5.00 (lat), 27.00 (long) to coordinate 10.00 (lat), 27.00 (long) you are traveling a distance of 5 degrees latitude (roughly 550 km). Your start point is located in Congo Democratic Republic and your end point in Sudan, as you can see in NNM Map Viewer.

You get interesting results here also. You will cross the following country borders from south to north: Congo Democratic Republic (UTC+2), Central African Republic (UTC+1), South Sudan (UTC+3) and Sudan (UTC+2). You will have the following four time zones during your trip: UTC+2, UTC+1, UTC+3, UTC+2.

The 80th longitude

If you travel the line from coordinate 28.00 (lat), 80.50 (long) to coordinate 72.00 (lat), 80.50 (long) you are traveling a distance of 44 degrees latitude (roughly 5000 km). Your start point is located in India and your end point in Russia, as you can see in NNM Map Viewer.

You will cross the following country borders from south to north: India, Nepal, India, China, Kazakhstan, China, Kazakhstan and Russia. Since different parts of Russia use different time zones, you will at least have the following ten time zones during your trip: UTC+5:30, UTC+5:45, UTC+5:30, UTC+8, UTC+6, UTC+8, UTC+6, UTC+7, UTC+5, UTC+7.

Deciding offset from your country

Trying to get your offset from country alone, will often fail. It may work for some, often small, countries. But for many countries it is impossible to get a correct offset, since the country may use several time zones. Even for small countries it may be impossible, since daylight saving time may trick you.

Note: Sweden uses only one time zone, but you can not say that Sweden uses offset UTC+01:00, since half of the year the actual offset is UTC+02:00 (due to daylight saving time).
This also means that if you have a company in Sweden, you can not statically say that your opening hours are "10:00 - 18:00 CET". That will most certainly be a complete lie when the rest of Sweden is using CEST. You have to dynamically update your opening hours information during the year, to stay in sync with the daylight saving time switches.
Yes, you may live in the exact same location all year, but you may not live in the same time zone all year.

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.
Most countries have gone through an amazing list of strange decision-making in this area during this [20th] century. Short of coming to their senses and abolishing the whole thing, we might expect that the rules for daylight saving time will remain the same for some time to come, but there is no guarantee.

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.

By the way, when using daylight saving time, should I move the clock forward or backward? Does DST work the same way in the Southern hemisphere as in the Northern hemisphere?

Note: The correct term is Daylight Saving Time and not Daylight Savings Time, but if misspelled in quotes or resource links I have left the word Savings untouched. I will do my best to use the correct term myself.

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.
Because our ancestors were morons, they opted for a system wherein many governments shift around the local time twice a year for no good reason. And it's not like they do it in a neat, coordinated fashion. No, they do it whimsically, varying the shifts' timing from country to country (or region to region!) and from year to year. And of course, they do it the opposite way south of the Equator. This all a tremendous waste of everyone's energy and, er, time, but it is how the world works and a date and a time library has to deal with it.
DST is controversial. More than 140 countries have used it at some point, but about half of them have since abolished it again.

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.

Time difference between two places

Thanks to DST, the time difference between two places can vary during a year with confusing results.

The Equator as a divider

If the two places are on opposite sides of the Equator, it gets even stranger. 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 between three distinct values during a year. 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+11:00  10h  2017-03-25T10:00+01:00
    2017-03-26T20:00+11:00   9h  2017-03-26T11:00+02:00
    2017-04-03T20:00+10:00   8h  2017-04-03T12:00+02:00
    2017-09-30T20:00+10:00   8h  2017-09-30T12:00+02:00
    2017-10-02T20:00+11:00   9h  2017-10-02T11:00+02:00
    2017-10-30T20:00+11:00  10h  2017-10-30T10:00+01:00

Even stranger it will be if comparing Stockholm and Windhoek in Namibia, which both had UTC+01:00 as standard time zone in 2017:

    Windhoek                     Stockholm
    2017-03-25T11:00+02:00   1h  2017-03-25T10:00+01:00
    2017-03-26T11:00+02:00   0h  2017-03-26T11:00+02:00
    2017-04-03T11:00+01:00  -1h  2017-04-03T12:00+02:00
    2017-09-01T11:00+01:00  -1h  2017-09-01T12:00+02:00
    2017-09-04T11:00+02:00   0h  2017-09-04T11:00+02:00
    2017-10-30T11:00+02:00   1h  2017-10-30T10:00+01:00

Note: Thankfully, Namibia has now skipped DST switches and instead uses UTC+0200 all year around.

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" (as defined by the ISO 8601 standard).

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: 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 their 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 into the timekeeping, so in some places we switch to and from "summer time" four times per year (instead of the usual two times per year). Why is religion intertwined with timekeeping?

Note: Moroccan authorities have (with very little forward planning) changed their minds about DST switches. They will still use the confusing Central European Time (CET) time zone though.

Note: I stand corrected, the nightmare in Morocco is not over yet.

This year's time changes in Morocco are unique on a global scale since Daylight Saving Time (DST) is usually one hour ahead of standard time, while Morocco will turn clocks back for about one month.

Special events


Sometimes, large sport events (like the Olympic Games) may change the DST rules. This is as bad as religion mixed into timekeeping.


As if this is not bad enough, the Brazilian authorities have come up with the idea that school exams should be mixed into timekeeping. Sadly, this is not a joke either. So the decisions that Brazil made less than one year before, did not work as planned.

We wonder how many students will show up one hour early for the test, as a result of mobile phones showing the wrong time.

Note: So the efforts to make the students well-rested before the exams, will instead make the students even more tired, since many of them will be anxious about if their alarm clocks will wake them up correctly on the exam day. Would it not be better to postpone the time for the exams with one hour instead of changing the DST rules with so little forward planning?

Note: It will also be interesting to see how many people that will have trouble to know when a meeting should start during those two weeks. Seems as mechanical watches will be the thing to rely on.

Note: Yes, of course, the Brazilian authorities changed their minds once again, just a few days after their first decision, when they realized that they had not fully understand what they were about to do. But it was a close one this time and I leave this section as a reminder of what can happen anytime.

Why building obstacles?

Why do people think that it would be so hard to make a change and abolish DST? Take the following quote regarding the EU discussions of DST for example:

Even when a law to scrap DST has been established, it will likely take some time until it is actually implemented. Updating all systems affected by the change all across Europe is a huge task, and legislators will probably be mindful of that, allowing ample time for the technical implementation.

Why would it be a huge task to update all systems when abandoning DST? I think it will be quite easy to skip using DST (as you will see in a step-by-step solution in the Conclusions/summary section below). A system handling DST today is hopefully dependent on the TZ database (or similar) so the system works correctly. So the only task needed is to update the TZ database with the skipped DST for the corresponding time zone rules, therefore the technical implementation part will be really easy.

Note: The countries in EU are hopefully about to abolish the DST switches during 2019. One of the propositions seems to be that each country can decide which time zone they will use. Either they use their standard time zone or their "summertime" time zone. But, a country can also choose whatever time zone they want.
What a blessing it would be if all EU countries should choose to use the UTC time zone. All year round. That would truly be pioneering.

Note: Some people in south of Sweden and in Denmark are afraid that Denmark and Sweden will choose different time zones and that it will be misunderstandings and confusion with train tables and working hours for those that commute. But wait, isn't that already a "problem" in the north of Sweden and Finland? And around each and every time zone border around the world? In fact, isn't that one of the main problems (and main purposes) with time zones? If it is a real problem with different local times, shouldn't we get rid of all time zones then?

Summary for DST

Perhaps DST is the most dreadful invention in our current timekeeping system.

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). When we do things should of course be decided locally, but what time it is when doing these things should be globally understandable.

Note: If you have not been convinced yet, just look at these wonderful videos: Daylight Saving - Movie Trailer, the sequel Daylight Saving: Spring Forward - Movie Trailer or Daylight Saving Time - How Is This Still A Thing?.

It would put an end to the twice-a-year routine of moving the clock either an hour ahead or an hour behind – something a business magazine calls “humanity’s dumbest ritual of all time.”
In temperate northern countries, DST usually starts late March/early April and ends late October/early November; exact start dates vary by country. Equatorial nations typically use no DST; southern nations will use dates that match their local summer. It's not unheard of for an individual province or state — or even a piece of one province — to opt out of a DST scheme in effect in the rest of the same nation. Due to the nature of daylight saving time the difference in time zones may vary during the year as one country doesn't have daylight saving time while the other does, or both have it but start at different times. However due to increasing commerce and international communication via the internet and other nearly instantaneous modes, there are increasing efforts to harmonize those things, especially among direct neighbors or political entities with good relations with each other.

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.

Note: Setting the clocks after the solar noon was a good idea until the 19th century. But now it is the 21st century and this is not a good idea anymore. Furthermore, the current time zones misuse the concept of solar noon.

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.

Just looking at the table for time zones in Australia makes me dizzy.

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 driving the correct route from the Arizona state border through both Navajo and Hopi areas to the other side one can end up changing one's clock 7 times!

Let us 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 switch to DST, that happened 2017-03-12. There is exactly one hour on the timeline between each row:

    Honolulu      Los Angeles   Chicago
    21:00-10  2h  23:00-08  2h  01:00-06
    22:00-10  2h  00:00-08  3h  03:00-05
    23:00-10  2h  01:00-08  3h  04:00-05
    00:00-10  3h  03:00-07  2h  05:00-05
    01:00-10  3h  04:00-07  2h  06:00-05
    02:00-10  3h  05:00-07  2h  07:00-05
    03:00-10  3h  06:00-07  2h  08:00-05
    04:00-10  3h  07:00-07  2h  09:00-05

Note: I have skipped the minutes part in the UTC offsets. Instead of using 21:00-10:00 I used 21:00-10. It would be even harder to understand the table otherwise. 03:00-07:00 could easily be mistaken as a four hour interval (instead of "three o'clock in UTC-0700"), while it is less risk with 03:00-07.

So before the DST switch, the time difference between Honolulu and Los Angeles was 2 hours and between Los Angeles and Chicago also 2 hours. But since Honolulu did not use DST, during the 150+ days that DST was active, the time difference was 3 hours between Honolulu and Los Angeles, but still 2 hours between Los Angeles and Chicago.

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, if you are unfamiliar with the detailed information about the state? Texas is also using two time zones, MST (Mountain Standard Time) and CST (Central Standard Time), within the state. As a matter of fact, several other states are also using two time zones, for example Indiana.

With businesses on one side of the street being in a different time zone from those on the other.
Indiana businesses have lost hours of productive time with out-of-state colleagues because the time quirks are too confusing to keep track of on a daily basis.

Note: A detailed information page about time zones in Florida can be quite complex. And this is just to keep track of what the time is in this small part of the world.

Yes, it is also a mystery to me how the people in the 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. Currently 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 at the moment to decide time differences within Russia than within the other two countries.

The 2010s

One problem in Russia though is that during the 2010s the time zones have been reduced and shuffled around from year to year. Russia used nine time zones during a couple of years and during this time they completely skipped to use the UTC+4 offset. Many locations had to switch their actual time zone or offset back and forth.

Russia has a history of time zone changes.

Note: If you want some details, please read:

So yes, it is also a mystery to me how the people in Russia know what the time difference is between two random places in their own country on a random date.


Mexico has four different time zones. The time changes within Mexico during a year are hard to understand.

With its varying Daylight Saving Time (DST) schedules, Mexico's time zone situation frequently causes confusion.

A few northern Mexican border towns, such as Tijuana and Juárez (Ciudad Juárez), start DST on March 11 along with the US and Canada.
However, most of Mexico starts DST on Sunday, April 1, 2018. A few Mexican cities, like Hermosillo and Cancun, do not observe DST at all.

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.

Note: 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...

Border between China and Afghanistan

If you wander about aimlessly in the nature reserve at the China and Afghanistan border, you may have to adjust your clock 3.5 hours from one step to another, if you want to keep up with the correct local time.

The border marks the greatest terrestrial time zone difference on Earth, with a 3.5 hour difference between Afghanistan's UTC+4:30 and China's UTC+08:00.


Norway is a small, but wide, country. Norway spans three different time zones, but uses just one. The standard time used everywhere is UTC+0100, although the westernmost parts could use UTC+0000 and the easternmost parts UTC+0200.

Since Norway lies relatively far from the equator and is stretched in southwest-northeast direction, this have some interesting effects.

Comparing Bergen and Kirkenes

If we compare the local times for sunrise and sunset in Bergen (a city in the southwest part) and Kirkenes (a city in the northeast part) during some interesting dates in 2018:

                       Kirkenes             Bergen
                    Sunrise  Sunset    Sunrise  Sunset
    January 28      09:03    13:23     09:04    16:39
    March 18        05:09    17:08     06:46    18:48
    May 6           02:06    21:51     05:21    21:50
    November 14     08:36    12:51     08:36    16:09

Note: View Bergen and Kirkenes in NNM Map Viewer (with longitudes -7.5, 7.5, 22.5 and 37.5 marked, i.e. indicating the ideal time zones for UTC+0000, UTC+0100 and UTC+0200).

January 28 and November 14, the Sun rises at the same local time at both places, but sets more than three hours later in Bergen, thanks to the tilted Earth. May 6, it is the other way around, the Sun sets the same time, but rises three hours earlier in Kirkenes.

March 18, the "daylength" is 12 hours at both places, although Kirkenes is more than 90 minutes "ahead of" Bergen.

In Kirkenes, during a part of the summer the Sun is "up all day" and during a part of the winter the Sun is "down all day", which makes the city a great example of that you can not conclude if the Sun is up or not from local time alone.

Note: The above "local time issues" in Norway are of course not "time zone problems", they are more "tilted globe" issues.

Countries changing time zone

Sometimes a country, for whatever reason they want, decides to change the time zone (UTC offset) they are using. For example Kiribati (1995), Samoa (2011) and North Korea (2015).

Parts of countries changing time zone

Sometimes a part of a country, for whatever reason they want, decides to change the time zone they are using. For example the states Maine and Massachusetts (in the United States of America).

Computer systems

When you see a timestamp without a time zone or offset notation (e.g. 2017-04-13T20:30:40), 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?

Note: No, of course a timestamp without time zone notation can not be a proper timestamp (see details in the Converting date and time values section below).

If you on the other hand, always would have to show the time zone or offset notations for timestamps (e.g. 2017-04-13T20:30:40+08:00), 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 are using.

This also means that you may have to configure your time zone in your computer settings, in your browser(s) settings and in all your applications settings. You may also have to readjust all these settings if they get out of sync for some reason. Most certainly, there is no trivial way of seeing all your configured values, so you have to quest for them all around your systems.

Note: If I see a "timestamp" like 2019-02-03 14:15:00 in my own computer and someone ask me what point in time that value represents, I always have to answer "I have not the slightest idea".
That would in fact always be my answer whenever I see "timestamps" missing vital information.

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.

Note: As a matter of fact, even if you know all of her settings, you can not fully understand the value, since you will not have a clue about which of the settings, if any, that is used. Unless you dig deep into the program code.

The AngularJS datetime filter uses the time zone settings of the browser. The same application will show different time information depending on the time zone settings of the computer that the application is running on. Neither JavaScript nor AngularJS currently supports displaying the date with a timezone specified by the developer.

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

Configuring time zone

Configuring your time zone in computer systems is often a confusing task. Even when using applications from global companies, you can not fully understand what you have configured. Far too often when configuring your time zone you have options like Europe/Stockholm (UTC+01:00). During standard time it would be okay, but since Stockholm is using DST half of the year, this option value is instead very confusing to put it mildly. If the option would be shown as Europe/Stockholm (UTC+02:00) during DST it would be (a bit more) understandable, but when using Europe/Stockholm (UTC+01:00) it will be ambiguous, since you can not understand if your time values are shown in UTC+01:00 or UTC+02:00.

Note: Using Europe/Stockholm (UTC+01:00) in Sweden during DST is not just ambiguous, in fact it is completely wrong.
You have to remember that an identifier and an offset are not the same. The identifier America/New_York is sometimes "equal" to the UTC-05:00 offset, but that same identifier is sometimes instead "equal" to UTC-04:00. So you should not mix identifiers and offsets statically together as in America/New_York (UTC-05:00).
In one way or another, if you really must mix identifiers and offsets together, you have to indicate if DST is currently active for an option. It could for example be America/New_York (UTC-04:00) or America/New_York (UTC-05:00)* during DST. Otherwise you have to stick to only using the identifier America/New_York.

Converting date and time values

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

Many people do not know how important it is to define a correct time zone when they are defining a timestamp.

If you have a timestamp without a time zone or offset notation (e.g. 2017-04-13T20:30:40), 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 has 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).

Note: If you want to be correct when presenting a timestamp, you must define the UTC offset (or something similar). Otherwise it would be like presenting a weight as 115, a distance as 203, a duration as 48.7 or a speed as 37.6, which make no sense at all to anyone.

Writing for the Internet

When you publish texts on the World Wide Web, you have to think twice when you are writing date and time values. Your text may be read by people anywhere on the globe, so you have to go that extra mile in order to not leave your readers in frustration.

It is not enough to use datetime values like 2019-04-14 09:35, because that will probably be ambiguous to everyone. If it is important that the value represents an actual timestamp, you have to add an (unambiguous) unit. Otherwise, if the exact time is not so important, you can perhaps lower the precision and only show the date part 2019-04-14. This will of course give your value a 50 hours timespan (as described in the Dates - are they too long? section below), but at least your readers will not have any false assumptions on your "timestamp".

Note: You have to understand that the (local) datetime values 2018-01-28 23:40 and 2018-01-30 01:40 can represent the exact same time on the timeline, depending on where you live. Yes, it should be January 28 and January 30.

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.

Take for example the coming timestamp 2028-07-23 12:50 Europe/Stockholm. It may represent the same point on the timeline as 2028-07-23 12:50 CEST or 2028-07-23 12:50 +02:00. But, if Sweden has abandoned Daylight Saving Time by then, it could instead represent 2028-07-23 12:50 CET or 2028-07-23 12:50 +01:00 (or something completely else for that matter).

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.

Note: It is "interesting" to read about the process for changing time zones in the United States. In the section "Substantive Requirements", you learn that you must consider television and radio broadcasts, newspapers, bus and train services, airports, where residents work, the community's economy and much more, when deciding a good time zone to use.

Nautical time zones

To make things even worse we have the nautical time zones. To be able to know what time it is, you now have to distinguish between if you are on land, in territorial water or in international water. It is hard to be a human.

Note: Nautical time zones are at least more predictable, since they follow the longitudes and are not skewed.

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

Same same, but different

Another implication with this strange use of time zone abbreviations is that countries using for example CET do not have to be in the same offset all year around. Not all of the countries using CET as standard time zone use Daylight Saving Time. So during half of the year Algeria and Sweden use the same time zone, CET, but during the other half of the year they are in different time zones, CET and CEST respectively.

Different calendar systems

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

Date formats

That search should search midnight september 6th to midnight on September 7th. But it doesn't. It searches from June 9th to July 9th.

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.

Visitors to a web site from varying locales may be confused by date formats. The format MM/DD/YY is unique to the United States (but sometimes used in Canada, too, which can obviously create some confusion there). Most of Europe uses DD/MM/YY. Japan uses YY/MM/DD. The separators may be slashes, dashes or periods. Some locales print leading zeroes, others suppress them. If a native Japanese speaker is reading a US English web page from a web site in Germany that contains the date 03/04/02 how do they interpret it?

Note: The date format examples yyyy-mm-dd, mm/dd/yy and dd/mm/yy are of course only a small subset of the complex list of all the date formats that have been invented around the world. Understanding the date and time notation in the United States is not trivial.

Date and time notation in the United States differs from that used in nearly all other countries.
This order [year-month-day] is also used within the Federal Aviation Administration and military because of the need to eliminate ambiguity.

Note: As a matter of fact, the formats mm/dd/yy and dd/mm/yy are often used without zero-padded values for month and day of month. So instead of the date 06/07/19 or 07/06/19 many countries use 6/7/19 or 7/6/19. The best part of the last sentence is that you have no idea if I meant June 7 or July 6.

Note: A real example from a Swedish car-dealer: The offer expires 190831. Saving a few characters, instead of being unambiguous and write 2019-08-31.

Note: No, it will not be better from the year 2032. It will still be impossible to distinguish the day and month (except for the day values 13-31).

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.

Therefore, one of the advantages with ISO 8601 is that date, time and datetime values can be easily sorted. Try doing that with dates in the mm/dd/yy or dd/mm/yy formats.

Implicitly configured date formats

Never mix the configuration of a user's date format with the configuration of her language. Trying to be smart and implicitly set her date format from her choice of language, will always irritate people. Language and date format should be kept completely separated and a user should always be able to configure them independently.

A user may want to use Swedish, but not have date values like 7/4 -19 thrown in her face. She may still want to see understandable date values like 2019-04-07. The same user may as well want to use English, but not be forced to see date values like 04/07/19.

Note: You would not come up with the idea to force strange length units onto users, when they select language, would you? If a Swedish user selects English as language, would you implicitly force her to see miles, yards and inches, instead of kilometers, meters and centimeters?

Note: Why is it so hard to get things right when a user should configure her date/time settings in applications?
When trying to use Teams (from one of the world's largest tech companies), you are supposed to be able to configure your language, date format, time format and time zone. But I have no clue how to get it right. Their documentation says Selecting your preferred language and region also updates your date and time zone. How can they even mix language with time/date? I want to have English as language, but if I choose "English (US)" I have to stick with the useless mm/dd/yy date format and of course the horrible AM/PM notation for time values. If instead using "English (UK)" I get the date format dd/mm/yy, which is also useless. There is no way that I can configure English as language and ISO 8601 as date/time format.
As I understand it, choosing the language "English (US)" is also an implicit selection of the region (which I guess is "US" in this case). So when region is "US" I am forced to use mm/dd/yy as described above. But which time zone do I get in this case? Implicitly setting a time zone from region "US" can never work. Or am I missing something?
Why is configuring date and time formats still a problem in 2019? Why are we still mixing languages with date/time formats? Who came up with the bright idea that when choosing your language, your date and time formats are implicitly chosen (and can not be changed independently)? As so many already pointed out, why not always use ISO 8601 as the default format for everyone? Why having the horrible "US" format as default for a global product?
Trying to define the date and time format in Twitter is not doable. I want to have English as language here also, but then the dreadful AM/PM notation with its 12-hour clock show up. I can not find a way to distinguish the language from the date and time format. When switching to Swedish, I get a time format that at least uses the 24-hour clock, but the language then is, well, Swedish.

Note: When trying to add an appointment in Outlook (from the same large tech company as Teams above) I literally get the following when trying to choose the time: 2019-05-29 08:00 (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna. The problem is that Stockholm and probably all the other cities use Daylight Saving Time that time of the year, so the actual offset May 29 is in fact UTC+02:00. So will the booking actually be from 08:00 or 09:00 that day? I don't know, I can only hope for the best, but I am not in control.

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?

As seen from members of the 24-hour world, the order 12,1,2,...11,12,1,2,...,11 as mapped onto 0,1,2...,23 is not only confusing, it is nearly impossible to make people believe that 13 hours have elapsed from 11 AM to 12 AM.

When using the 24-hour clock, times are usually written with exactly five characters, for example 09:45 or 22:20. When using 12-hour clock, you need up to three more characters and the length varies, for example 9:45 AM or 10:20 PM. If you want to use a more correct notation you need two characters more, for example 9:45 a.m. or 10:20 p.m..

Are there any benefits of using AM/PM? I can't come up with any. Not a single one. 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.

In the practice of medicine the 24-hour clock is generally used in documentation of care as it prevents any ambiguity as to when events occurred in a patient's medical history.
The 24-hour clock is commonly used there [12-hour clock countries] only in some specialist areas (military, aviation, navigation, tourism, meteorology, astronomy, computing, logistics, emergency services, hospitals), where the ambiguities of the 12-hour notation are deemed too inconvenient, cumbersome, or dangerous.

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

The loss of 12-hour clocks will annoy a few people for a time, but there is nothing quite like shaking a bad habit for good.

Note: Hilarious discussions about 12:00 PM and 12:00 AM.

Note: Perhaps writing AM/PM or am/pm is wrong. Perhaps the correct way should be to write a.m./p.m. or A.M./P.M. (at least in some language in some part of the world).

Note: I think that the biggest problem and most confusing part with AM/PM notation is that the sequence is numbered 12, 1, 2, ..., 10, 11 and not 0, 1, 2, ..., 10, 11. If using 0 instead of 12 there would be more logic in using AM/PM and it would conform more to the rest of the date and time values. The months are not numbered 12, 1, 2, ..., 10, 11 and the minutes or seconds are not numbered 60, 1, 2, ..., 58, 59. Yes, there is a subtle difference between the date values and the time values, since the months and days of month start at 1, while the hours, minutes and seconds start at 0.

Note: Another problem is that the AM/PM is often left out and should implicitly be understood by context. That is like leaving the month out and just present the day of the month. Saying "I see you on the 17th" may work, as well as saying "I see you 8:30", but there may be misunderstandings involved.

Note: Yes, there are also the 6-hour clock, the 30-hour clock and numerous other variants, but please, let us not dig deeper into those.

Note: One of the better usages of a 12-hour clock face is when used as clock position.

Problems with watches

You may think that you can always trust a good old watch, but lo and behold, you are in for a surprise.

Mechanical watches

You may have invested in a manual mechanical watch that is precise and keeps the pace perfectly day after day. Unfortunately, you can never trust its value when you are travelling. If your clock is not connected to the Internet or GPS or if it lacks an embedded computer, you will never know how to adjust your clock. Your watch does not have access to the rules contained in the TZ database (or similar). To summarize, you can tell everyone the exact duration of your trip, but you may not be able to tell anyone what the current time is.

Note: Yes, you can (hopefully, but not certainly) get correct local time from the wall-times in the airport, train station etc or ask someone or ask the Internet. But, you are dependent on something/someone else to know the current time and can not use your mechanical watch alone.

In fact, even if you are at the exact same spot all the time, you can not trust the value on your precious watch. Either the country you are in can change its time zone rules or there may be a Daylight Saving Time switch, so your watch suddenly will be an hour (or so) off. This will of course be true for every type of mechanical clock (including wall-clocks and perfectly paced Swiss-made ones). You have to remember, you can not hide from the disastrous DST demon.

Manual vs automatic watches

When you have a manual watch, you must set it correctly yourself. You also need to adjust the time manually when changing time zone or when DST switches occur. You are in control of the time you see, and you can trust the time value and corresponding time zone, since it will not change without your help. Even if you don't see any explicit time zone value, you can (almost) be sure that the watch is showing the correct time for the time zone you set it for.

Note: You can not be sure that the time is correct for your location though (as discussed in the previous section).

When you have an automatic watch, you may not need to set or adjust it yourself. The watch may get correct information from satellites, wifi, radio signals, etc. But if you don't see an explicit time zone value, you can not trust the time value at all. This is because you may have entered a different time zone, it may have been a DST switch, or the watch may (erroneously) have switched to another time zone. So in order to minimize the occasions you see an incorrect time value on your watch, you need to see the current time zone as well.

Note: Of course, the time zone must be expressed with offset to UTC, since an identifier or abbreviation is not enough, due to the fact that your automatic watch may have implemented an incorrect or outdated version of the time zone rules. As an example of the problems for automatic watches, think about the mornings you wake up after a DST switch. If you look at the time value on your watch, mobile phone or computer, you have no idea if it is the correct local time until you have double checked the actual time zone value.

Note: An example of problems encountered when your device will switch erroneously to the wrong time zone. No, it is no better with other brands, so please stop laughing.

So when an iPhone says it’s 12:46 p.m., you expect that to be true.
Use another timekeeper. This may be a frustrating solution, but it can keep you from missing important appointments. Use the in-room hotel clock, wear a watch to keep the time accurate, or buy a cheap and portable alarm clock to carry with you.

A wonderful example of a person thinking outside the box and taking advantage of the local times:

I travel to India every month...They are 5.5 hours ahead of GMT....this is a great advantage when I'm there (when I've set my watch to Indian time) if I want to know the time in the UK, I just turn my watch upside-down.

Airports and other locations

"Why do airports manage to handle which time zone they are in?", you may ask. First, an airport always has its defined location. Second, the number of airports is a small finite number. So each airport around the world can easily be mapped to a specific time zone. Even if there should be a million airports (which there is not), it is a manageable number to handle.

It is the same with addresses. The set of addresses, although much larger than the set of airports, is also a finite set. Even if there are many billions of addresses around the world, you can map each address to a specific time zone. But now it is getting a bit harder to manage the mappings.

Note: This is the reason that it often is no problem choosing dates when you want to book a hotel or a flight. There are many hotels and airports around the world, but they all know their time zone.

The problem is how to handle all the locations between defined addresses. Since the time zones are no straight lines between the poles, you can not use your east-west position to map to your current time zone. So you need a mapping from your coordinates to a time zone. But how fine-grained should this coordinate system be so you unambiguously know what the local time is?

Note: The little island Märket is an interesting example of a country border that also serves as a time zone border. Think of the precision that a GPS watch must have to show correct local time (NNM Map Viewer). By walking less than 200 meters from west to east you are in the following standard time zones: UTC+01, UTC+02, UTC+01, UTC+02, UTC+01 and UTC+02.

Note: Another example is the three-country cairn between Norway, Finland and Russia (NNM Map Viewer). When walking around in this area your clock has to keep up with switching between UTC+01, UTC+02 and UTC+03.

You don't even have to cross a country border. If you are in the northwest areas of Florida or somewhere around El Paso in Texas, how would you know what (local) time it is?

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: This is my proposal, which is one among many other proposals. I emphasize that it does not really matter what we use in the future, the important part is that we make a change to something better than the timekeeping we use today. Or as Absurd Minds put it in their song Now we hear the call: Time is ticking by. Get started straight away. Or will you wait another day? Time is ticking by. The right time is today. Just don't care what others say!.

Note: I will use London (due to the history of Greenwich and GMT/UTC) as the "starting point" of a new date 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 (almost) 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.

An online meeting scheduled for 2020-04-13T20:00Z, will start at 20:00 for everyone.

A six hours flight starting at 08:20 local time will always land at 14:20 local time. It does not matter if you are flying north, east, south or west. It does not even matter if your speed is 1500 km/h or 200 km/h. The clock will always be 14:20 wherever you land. And the other way around, a flight starting at 16:35 local time and landing 19:55 local time is always taking 3 hours and 20 minutes.

The date line will be no more, since the date always will be the same everywhere. There will not be any strange 24 hours leaps and you would not be able to travel back and forth in time anymore.

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. At the moment, 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


Note: There are some mitigating circumstances for Kiribati if I understand it correctly. Before inventing UTC+1400 and UTC+1300, Kiribati used three time zones (UTC+1200, UTC-1100 and UTC-1000), since the International Date Line went straight across the country. As you see, these were not consecutive. Instead the time difference was 23 hours between some parts of the country. Nowadays the country uses UTC+1200, UTC+1300 and UTC+1400 instead, with a maximum time difference of two hours within the country. But it still is an increase in complexity for timekeeping in the world. And hopefully Kiribati will not start to use Daylight Saving Time.
But (yes, there is always a but), you have to understand what Kiribati instead could have done though. They could have solved their problem by changing the UTC+1200 to UTC-1200 and none of us should have had UTC+1300 and UTC+1400 thrown upon us.

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+14:00 (Tuesday)
    2018-01-29T23:59:59+12:00 (Monday)
    2018-01-29T11:59:59+00:00 (Monday)
    2018-01-28T23:59:59-12:00 (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.

Note: The three answers could be something like this. Person in UTC+1300: "It happened just after midnight Tuesday morning". Person in UTC+1200: "No, it happened just before midnight Monday evening". Person in UTC-1200: "No, no, no, I am sure it happened just before midnight Sunday evening".

Note: A real example really present 2019-07-20 is the confusion involved about when mankind first landed on the Moon. Eagle, the lunar module from Apollo 11, landed on Sunday July 20, 1969. That is correct for Europe, Africa and America, but for most of Asia and Australia the landing was at Monday July 21, 1969. The exact time in UTC for the landing was 1969-07-20T20:17:40Z.
The time for the first step on the Moon, a few hours later, is also confusing. In UTC it was 1969-07-21T02:56:15Z. This corresponds to July 21 for most of the world, but for USA it was still July 20.

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


Note: Another real example is that when talking about the moment in time when equinox takes place you may have to say: September Equinox takes place on September 22 or 23 depending on your time zone.

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.

Ambiguous definitions related to location

It is the same with dawn, morning, noon, afternoon, dusk, evening, midnight, today, yesterday, tomorrow, etc. Those are strongly related to your location.

Timekeeping should not have anything to do with location specific observations. Timekeeping should be precise. Day, night, dawn, morning, noon, afternoon, dusk, evening, midnight, today, yesterday, tomorrow are ambiguous.

Note: If your boss asks you to present all the major events that happened in your company yesterday, how will you solve your task? If your company is located in New York, would you use New York's time zone then? What if your company is spread all over the US? Would you make yesterday span 29 (or perhaps 30) hours instead of 24 hours then? What if your company is global? Would you use the 50 hours span then? If your boss is located in Tokyo and you are in New York, which time span would you then use in your search?
When asked for events the last 24, 48 or 72 hours your task is understandable, because that would be exactly the same for New York, the US and globally. But when asked for events yesterday, today, previous week, previous month, etc, the task becomes ambiguous.

Note: Using today, yesterday and tomorrow as time span identifiers in searches is confusing. Should a person in Tokyo get the same result as a person in New York? If the person in New York searches in the time span yesterday and then she travels to Los Angeles and performs the same search, should the result be the same?
Instead of these ambiguous searches, the user should have to define exactly what she looks for. It should be the user that defines the time span, not a product owner or system developer assuming/guessing what today, yesterday and tomorrow are supposed to mean.
Yes, the form would be a bit more complex to fill in, but now your query would be understandable. If you live in New York and want to search for events that happened yesterday, you may have to define the time span as 2018-10-17T00:00:00-04:00 - 2018-10-18T00:00:00-04:00 (or better yet 2018-10-17T04:00:00Z - 2018-10-18T04:00:00Z), but you are in charge of your query. As a bonus, if you instead want the result for Los Angeles you just change your time span to 2018-10-17T07:00:00Z - 2018-10-18T07:00:00Z (and you do not have to travel to Los Angeles or change obscure time zone settings in your computer).

Note: As a specific example of a problem. Suppose you have a global service for searching among events. For "simplicity" the servers are running in UTC. One user is located in time zone UTC+07, another user in UTC and a third user in UTC-05.
At 2019-05-01T01:25Z all three users are asked to get the events from yesterday. The UTC+07 user has a local time of 2019-05-01T08:25+07:00, so she will get the events from 2019-04-30. The UTC user has a local time of 2019-05-01T01:25Z, so she will also get the events from 2019-04-30. But the UTC-05 user has a local time of 2019-04-30T20:25-05:00, so she will instead get the events from 2019-04-29.
Of course, the problems how exactly 2019-04-29 and 2019-04-30 should be interpreted in server time for the search query (as discussed in the previous note) are also present.

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? We have not been able to come to consensus if a week should start on Monday or Sunday (or some other day).

Previous, current and next week

Previous week, current week and next week. What does these mean? If it is Sunday May 19, is the previous week then Monday May 6 to Sunday May 12 for those of us that define a week to be Monday to Sunday? And for those of you defining a week as Sunday to Saturday, is previous week then instead Sunday May 12 to Saturday May 18? If you say that we should set up a meeting in next week, do you mean Monday May 20 to Sunday May 26 or Sunday May 26 to Saturday June 1?

Note: If it is Sunday May 19 in your time zone and Monday May 20 in my time zone, what will our interpretations of next week be? If I am a Monday-Sunday week person and you are a Sunday-Saturday week person, I will interpret next week as Monday May 27 to Sunday June 2 and you will interpret it as Sunday May 26 to Saturday June 1. But if I am Sunday-Saturday week person and you a Monday-Sunday week person, I will interpret next week as Sunday May 26 to Saturday June 1, while you interpret it as Monday May 20 to Sunday May 26.
If both of us are Monday-Sunday week persons I will interpret next week as Monday May 27 to Sunday June 2, while you interpret it as Monday May 20 to Sunday May 26.
It may be hard to find a day for a meeting under these circumstances.


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. But must we really have them "built in" to our timekeeping system?

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.

Counter-arguments from pessimists

There are many questions and counter-arguments that come up from fossils when alternative timekeeping systems are proposed. Here are some of them.

Yes, you have to rethink and relearn. Some parts may be a little harder to understand in the beginning, but a majority will always be a lot easier. Do you want to be a part of the problem, or a part of the solution?

The point of a common time is not to force everyone to do everything at the same time. It's to allow us to communicate unambiguously with each other about when we are doing things.

Note: The quote above defines the core of my reasoning about a common time, so please read it once again carefully.

The difference from today [if the whole world used a single GMT-based time] is that if you were putting together a London-LA conference call at 21:00 there'd be only one possible interpretation of the proposal. A flight that leaves New York at 14:00 and lands in Paris at 20:00 is a six-hour flight, with no need to keep track of time zones. If your appointment is in El Paso at 11:30 you don't need to remember that it's in a different time zone than the rest of Texas.

One of the best answers to the question "Regarding timezones, what are the pros and cons of just having one worldwide?" that I have stumbled upon so far:

For the pros; The time locally will be the same everywhere. The military and the aviation industry operate with one time zone. They call it Zulu time and it is set as Greenwich mean. It really doesn’t make any difference what time it is locally because your daily life will run with these anyway. So if the sun rises at 1200 hours locally your day will start then. There is no reason why it has to be 8:00 AM at morning everywhere. The cons: it will take some psychological adjustment but that is easily accomplished.


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. Of course we should also use a common date format.

Complexity, confusion, ambiguity, problems and errors are some of the most common words you see when reading about time zones, 12-hour clock and different date formats. 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?

To paraphrase myself: Timekeeping is science, time zones are nonsense.

To paraphrase Kaufmann and Freedman: Indeed, time zones are not a science at all, but merely a collection of superstitions and hokum that tries to use some of the terminology of timekeeping but which rejects the logical thinking that is at the heart of science.

Step-by-step solution

But wouldn't it be very difficult to do this? No, I really don't think so. In fact I think it would be quite easy. A step-by-step formula could be:

  1. Daylight Saving Time is a complicated and confusing part when talking about time zones. The time difference between two locations may vary during a year. Getting rid of DST is a first step (that's one small step for a man, one giant leap for mankind). At this point, since we are not using DST anymore, the time difference between two locations is static.
  2. Then we have the ambiguous and useless time zone abbreviations. Get rid of them in the next step.
  3. Let us also throw away the AM/PM and 12-hour clock notations.
  4. Then, start using the date format yyyy-mm-dd everywhere. At this point, we use the ISO 8601 formats for date, time and datetime values all around the globe.
  5. Next, only use time zone identifiers to identify which UTC offset to use. For example, "Europe/Stockholm" will always map to UTC+0100 (remember that DST is not used anymore so it is a one-to-one mapping now). The only format you will see for a timestamp in Sweden will then be like 2020-01-02T10:20:30+01:00. You will never have to see the insufficient time zone indicators like CET, CEST or Europe/Stockholm anymore in the timestamps.
  6. Now, the step to only use UTC+0000 everywhere would be almost trivial.

Note: All these steps will be easy to accomplish, since the TZ database already has functionality that handles all this. Several times during the previous years, countries have decided to abandon DST or have decided to switch to other offsets. That is well-tried, everyday functionality for the TZ database.

Unambiguous time

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 right 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.

Mechanical watches will be useful again since you can trust them.

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? Why is the answer to the question "What time is it?" dependent on our physical location on the Earth? In fact, the answer to the question is also dependent on the time of year! What have we done to deserve this? How can timekeeping be more complicated than rocket science? Time zones do not improve or simplify our lives. The time is out of joint.

Moral of the story

Time zones must be destroyed. Q.E.D. And they all lived happily ever after...

This is your world, these are your people. You can live for yourself today, or help build tomorrow for everyone.

Note: If you have spotted any errors in my examples, calculations and 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+08:00 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.

Note: My goal is to keep the content up-to-date, but as you now know, the time zone rules used for a location can be changed anytime and it is impossible to keep up with all changes. So after the different sections were written, the rules may have changed and the content may therefore be misleading. For example, at the moment Florida and North Korea have plans in changing their time zones. Of course, these out-of-date problems are also additional arguments in proving my point about time zones, so I am not the one crying.

Note: I want to emphasize, that I mean that time zones should be abolished when used together with timekeeping. When you see a time value, it should be obvious for everyone when that is. Of course, we will still need "time zones" in order to translate to "normal local working hours", to know when it is "normal" to wake up and go to sleep, to know when it is dark/light and other parts related to local custom and culture. The Earth will still rotate as long as we live here...

Note: The more I read about these topics, the more convinced I become that there must be better alternatives for them. For every time/date value I see, it would work as good using Zulu time and in many, many of these cases it would even work better with Zulu time.

Additional quotes

All the credits go to the original authors for all the quotes in this text, both in this section and everywhere else. Many thanks to all of you for your valuable contributions.

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.
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”.
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.
If you live in a country with Daylight Saving Time, your computers are (hopefully) changing time on their own twice a year. This is fine for your personal devices but a server with time-stamped log and/or backup files may run into issues twice a year during the switch.
A time zone is a region on Earth that has a uniform, legally mandated standard time. As legal definitions of zones can vary wildly and change often, a database or lookup table is often required to properly apply time zone rules.
UTC, also called Zulu time, is used everywhere on Earth by astronomers and others who need to state the time of an event unambiguously.
Daylight Saving Time is the period when a time zone shifts its time forward in the spring (usually by one hour) and then shifts back in the fall. This creates many programming issues dealing with the lost hour in the spring, and the extra hour in the fall.
This can lead to problems because some people think that you can always convert in either direction [between UTC and Local Time], which is false for any time zone that observes daylight saving time.
Governments of the world often make changes to how they want to follow DST. You cannot assume that the current rules have always applied in the past or always will apply in the future.
They [time zones] were a good idea at the time [19th century], but in the modern world they cause more trouble than they are worth.
It is genuinely annoying to schedule meetings, calls, and other arrangements across time zones.
Today, however, we are very accustomed to the idea that time zone boundaries should be bent for the sake of convenience and practicality. That means we should move to the most convenient and most practical time system of all — a single Earth Time for all of humanity.
From an astronomical point of view, the time is the same everywhere in the world right now.
The American Journal of Cardiology found a 10 percent increase in heart attacks on the Monday and Tuesday after the March weekend shift to DST. The Journal of Applied Psychology found an increase in the number and severity of injuries suffered by miners after the annual switch. And Accident Analysis & Prevention predicts a 13 percent reduction in pedestrian fatalities and 3 percent reduction in vehicular fatalities if the U.S. would stop resetting its clocks twice a year.
It’s amazing how many meetings get derailed because the times or dates were miscommunicated. For example, when writing a date, 4/9/18 could either be April 9 or September 4. Avoid potential misunderstandings by writing out the full date: April 9, 2018. Also ensure everyone knows what time the meeting is in their local time zone. This gets even trickier around daylight savings time, where different countries change at different times! To avoid any confusion, when sending meeting invites, include all the relevant time zones and be specific (e.g., 7 a.m. NY time, 1 p.m. (13:00) Paris time).
More power to Arizona for protesting one of the most annoying ideas humankind has ever come up with. /.../ Not all of our choices can be as great as the choice to ignore daylight saving time, evidently.
In January, 2015, a lawmaker proposed establishing daylight saving time. It was met with shock and outrage.
Local solar time was fine when almost all activity was local. Today, much activity is global and one time is called for.
Once you see this inevitable correspondence between the whole circle and the whole day, you’re liable to get confused by some of the current information design out there, when it’s based on the 12 hour dial.
Our system of time zones defies geographic reality, and means that natural time and civil time don’t always coincide.
You may miss an important obligation, or connections with scheduled transport, simply by not understanding what will be the correct local time as you travel.
Starting a 12–15 hour flight from the U.S. west coast to Japan or Hong Kong in late evening can land you there in the morning two calendar days later.
If starting the reverse course by midday, you may in a way "travel back in time" as you land earlier than you started. For example a typical flight from Sydney to LA will take off at lunchtime and land early in the morning on the same calendar date!
If your travel has time zone complexities or possible impacts on your health or comfort, consult an expert as you plan it.
Some time-zones seem to defy logic and were mostly drawn by national or regional governments to make commerce and administration easier.
As there is no universally agreed point of the year to change from standard to daylight saving time, there may also be "fluctuations" of up to several weeks when one country has already changed and the other hasn't. If you are traveling during that time or calling home, make sure to inform yourself of the local time at both your destination and point of origin.
Going west from France lets you stay in the same time zone (when you "should" have to change from Central European time to UTC) but going north from France to Britain you will have to change time-zone.
I am not about to stay at work until 11pm every day.
I do business globally. I know if I call my Japanese customers, it is tomorrow there and 13 hours ahead of my local time. If it was 24:00 here and I was ready to leave work, it would be 24:00 there and who the hell knows what part of the day.
Nope, not gonna do it. I know the sun rises between 6 and 7 in the a.m, noon is when the sun is highest in the sky, and the sun sets around 6 to 7 in the pm (roughly). That makes midnight sorta the middle of the night.
This is true no matter where I am on the globe, within reason and with adjustments for sunrise & sunset times due to latitude.
Programmers exist to make life more convenient for me; I don't exist to make life easier for programmers.
Due to daylight saving time, there is a possibility that a time either does not exist, or has existed twice.
Time zone detection is rather tricky to get right.
You usually don't need to worry about time zones. Your code runs on a computer with a particular time zone and everything will work consistently in that zone without you doing anything. It's when you want to do complicated stuff across zones that you have to think about it.
Time zones are pain in the ass.
Using the time zones can be confusing for several reasons. First, some countries have several different time zones, and those local zones don't always align perfectly with specific longitude lines. Also, remember that with 24 time zones the local time at another location can be anywhere from 0 to 24 hours different from you, and it can even be a different date!
Remember, that Time Zones, Offsets and Daylight Savings rules are not fixed and change (a lot more than you'd expect!).
When testing your applications make sure you test countries in each hemisphere, with both DST on and off. Test also transition from Summer Time to Winter Time and boundary cases (UTC+13) and half-hour time zones, at least.
While I think Daylight Savings is useless, unfortunately we still have to make sure that our applications work correctly until the rest of the world discovers that it's useless.
Little did I know at the time, I booked every appointment for eastern time (Florida) when I live in the central time zone (Texas). Every single meeting was scheduled for the wrong time.
I was in time zone hell.
If you left the Gilbert Islands /.../ on a boat and arrived at Baker Island or Howland Island, your watch would still be showing the correct time, but if it has a date display, the date would be one day off.
Time zones are thus a compromise, relaxing the complex geographic dependence while still allowing local time to approximate the mean solar time.
The increase in worldwide communication has further increased the need for interacting parties to communicate mutually comprehensible time references to one another.
Thus from west to east, time zones were: +6:00, +5:30, +5:45, +5:30, +8:00, +6:00, +5:30 and +6:30.
Pentagon officials were two hours late for an important military conference in Alaska because no one knew what time it was out there on the Russian border.
Norway, Finland, and western Russia observe three different time zones. As a result, this border region, near the Russian village of Nautsi, can get chronologically crazy.
So they could observe the arrival of the new millennium not one, not two, but three separate times.
Welcome to the world of standard time, where the only international rule is keeping your clocks in sync with UTC.
Everything else is open season. Everyone chooses their own standard time offset; everyone chooses when to switch to daylight saving time (or even whether or not to use it at all); everyone chooses their own time zone boundaries.
Daylight Saving Time is the greatest continuing fraud ever perpetrated on the American people. And this weekend, the effect of this cruel monster will rear its ugly head again. /.../ It's time to stop this insanity.
Good point about the idea that if everyone eliminated DST, we wouldn’t have to struggle with an added problem. Life is hard enough. Then we would only have to deal with time zones which is another animal.
It is amusing that when people specify a time, they tend to forget that they looked at their watches or asked other time-keeping devices at a particular geographic location. The value they use for current time is colored by this location so much that the absence of a location at which we have the current time, renders it completely useless -- it could be specified in any one of the about 30 (semantically different) timezones employed around the planet.
This piece of information is amazingly useless.
The basic problem with time is that we need to express both time and place whenever we want to place some event in time and space, yet we tend to assume spatial coordinates even more than we assume temporal coordinates, and in the case of time in ordinary communication, it is simply left out entirely. Despite the existence of time zones and strange daylight saving time regimes around the world, most people are blithely unaware of their own time zone and certainly of how it relates to standard references. Most people are equally unaware that by choosing a notation that is close to the spoken or written expression of dates, they make it meaningless to people who may not share the culture, but can still read the language. It is unlikely that people will change enough to put these issues to rest, so responsible computer people need to address the issues and resist the otherwise overpowering urge to abbreviate and drop context.
For some reason, precision in time always suffers when people are short of space.
The Roman tradition of starting the year in the month of March has also been lost. /.../ This means that month number 7, 8, 9, and 10 suddenly came in as number 9, 10, 11, and 12, but kept their names: September, October, November, December. This is of interest mostly to those who remember their Latin but far more important was the decision to retain the leap day in February. In the old calendar, the leap day was added at the end of the year, as makes perfect sense, when the month was already short, but now it is squeezed into the middle of the first quarter, complicating all sorts of calculations.
Making Februarius the second month, which explains why leap day is at such a funny point in the year.
There is nothing worse than doing an excellent job and then being penalised by the client for not meeting a deadline merely because of ignorance of time zones.
In 2019, this [March equinox] is on March 20, at 21:58 UTC. For locations that are more than two hours ahead UTC, it will be on March 21. This is because of the time zone difference.
These dates [March 19, 20 or 21] are based on the time of the equinox in UTC. Due to time zone differences, locations ahead of UTC may celebrate the March Equinox a day later, and locations behind UTC may celebrate it a day earlier.
It turns out humans have had a long, long history of poorly dealing with time, so when you hammer your head against the wall trying to deal with a timezone bug, well, you’re just the last in a long, long line of human beings that are terrible at all this!
This complicated everything, and made obvious the notion that writing timezone code was some of the worst things you have to do in our field.
Birthdays are kind of like floating events; it doesn’t really matter where you are on the planet; if the numerical day matches up with what’s on your driver’s license we’re set. Storing these things as a timestamp column instead of just a date column in your database can end up complicating your code down the line.
Also if you find yourself at this critical juncture, you might want to just give up programming entirely, because that sounds horrible.
I don’t know if you’ve noticed this yet, but Americans aren’t perfect. We use this fucked up date format, MM/DD/YYYY. Like under no circumstances does this make any sense.
The Brightest Point in Human History, also known as ISO 8601.
Some people believed it stole 11 days of their lives.
I can easily maintain a timezone list myself.
This is the second time in the space of three years that Metlakatla tampers with its time zone.
The time-zone map is a hodgepodge.
There’s plenty to argue about in cyberspace, as in the real world. We could at least agree on the time.
If an area switches their time zone, events created before we knew about the change might be in the wrong time zone.
That's a pretty bizarre way to divide a day up. We divide it in half, then divide the halves by twelfths, then divide the twelfths into sixtieths, then divide by 60 again, and then convert to a decimal system for the smallest increments. It's no wonder children have trouble learning how to tell time.
I think it's funny to see people complaining about the use of TimeZones because of how they interfere with certain highly specialized situations, as if the entire world, most of whom rarely travel more than a couple hundred miles from home and therefore don't give a rat's ass about TimeZones, should just drop everything and change the way they do things just to please programmers and other geeks.
How does one write a date on the Web? There are so many formats available, most of them incompatible with others, that it can be a usability nightmare to choose a date representation when writing for an international, cross-cultural audience, as is the case on the web. Fortunately, there is one solution in the ISO-developed international date format.
Your answer will depend, mostly, on which country you live in.
How can we expect peace in the region when they can’t coordinate time change?
This is madness and it must stop.
The purpose of uniform time measures is economic coordination. If economics were not the main concern, we’d all be on our own solar time, when the sun is directly overhead at noon.
But times have changed, and we still have times zones based on commerce and the global hegemony that prevailed in 1883. The modern world is even more integrated, equal and mobile, suggesting we’d benefit from fewer, more stable time zones.
If our sole objective were better economic coordination, we’d move to a single time zone. But you can have too much of a good thing. A single time zone removes people too far from their solar time, so time would start to lose all meaning.
Messing with time zones may upset our fragile global order, especially when time can be a hot political issue.
Now the world has evolved further – we are even more integrated and mobile, suggesting we’d benefit from fewer, more stable time zones. Why stick with a system designed for commerce in 1883?
The longitudinal distance of Alaska is nearly equal to the entire continental United States, yet the state functions, albeit with some tension, on one time zone. China has been on one time zone since 1949, despite naturally spanning five time zones.
Time is already arbitrary, why not make it work in our favor?
As tempting as it may seem, it is best to leave the application-wide time zone as UTC.
When working with APIs, it is best to use the ISO8601 standard, which represents date/time information as a string. ISO8601’s advantages are that the string is unambiguous, human readable, widely supported, and sortable.
We can only reset your time zone once, so please choose your new time zone carefully. Requests to change time zones must come from an Admin user, and your time zone may only be shifted eastward – for example, GMT (Greenwich Mean Time) to IST (India Standard Time). If your time zone has already been reset once at your request, we will not be able to change it again.
We feel your pain. Maybe a bit more quietly, since the editors of a productivity-minded blog don't like to reveal they missed a deadline or appointment due to EST/CST/PST confusion. But it's happened to us, it's happened to people we've been waiting on, even though we seemingly live in an age where this should all be figured out.
The thinking and methodology is the same: don't ever rely on your own brain to do the cross-time-zone math.
Since some states (I'm looking at you Kentucky and El Paso Texas) have more than one time zone, always ask the customer what time zone they are in. They may think that you are stupid, but it's better than being late.
[Sorry for the language in this quote] Fuck timezones. Fuck them and especially fuck Daylight Savings Time. And fuck having to conform to all this BS to avoid confusion just because the entire human race is fine with being dangerously insane.
If your software is only used in a single timezone, you might think that timezones are not necessary to think about. But being aware of the timezone is necessary in more situations than what most people assume.
In maths and physics classes in school I was taught to always keep track of the units when doing calculations.
I think that in general it is best if data is not silently created by default. /.../ It can be convenient in some cases. But convenience in one situation can be silent creation of bad data in another situation.
A unit is information. And wrong information is worse than a lack of information. Using wrong units is worse than not using any units.
The most important thing we can learn /.../ is that there is a many-to-many relationship between time zones and offsets. A time zone is a place that can map to different offsets, depending on what time of year it is or which year it is. At any given moment, an offset is usually shared by multiple time zones.
I can delight in all this mess or tear my hair out, and I choose to delight in it!
We are in Phoenix and for some reason my friends iPhone time zone set to Denver after she rebooted it. So she woke up an hour early today after daylight savings happened in Denver.
My iphpne X just decided it is 20th of November at 12:00 and refuses to change this.
That’s three weeks in a row that my alarm has woken me up an hour early because it thinks it’s 7am when actually 6am !
I set my iPhone to manual and choose my timezone. As soon when I reboot the device it’s again on automatic and then the wrong time zone. Very annoying, they really should fix it once for all.
It is by no means straightforward. You really have to do your homework to work out what the time is.
It is all much more confusing than if all countries stayed on the 24 hour time zone system.
Assume that you live in a region that does not observe daylight saving time (DST), but the Windows setting for that time zone does adjust for daylight saving time. In this situation, we recommend that you do not clear the Automatically adjust clock for Daylight Saving Time check box in the Time Zone Settings dialog box.
If you disable this daylight saving time functionality, Microsoft Outlook 2010 and Microsoft Outlook 2013 may assign the wrong time to a Calendar event, appointment, or meeting request for recipients in other time zones that do observe daylight saving time. Instead, we recommend that you select a time zone that does not observe daylight saving time and that has the same Coordinated Universal Time (UTC) offset as the current time zone.
Approximate answers will do so long as the students get times in the right ballpark.
Note that the times given here will vary from time to time depending on Daylight Saving. New Zealand and Australian Daylight Saving does not always begin and end on the same date. In addition, not all Australian States always go on Daylight Saving.
Russia’s President Dmitry Medvedev wants to reduce the number of time zones across the country to improve the nation’s economy.
He questioned if the time zone differences could impact on efficiently managing the country and the use of technology.
I found it really hard to handle time zone in JavaScript.
I had a valuable and thrilling experience of solving a problem leading to cause more problems.
For this to work, the date and time transferred from the client to the server must be values based on the same offset (usually UTC) or values that also include the time zone data of the client environment.
The return value of this method varies from browser to browser, and the format of the string type can affect the prediction of exact value.
A string like 2015–10–12 12:00:00 returns NaN on Safari and Internet Explorer while the same string returns the local time zone on Chrome and Firefox. In some cases, it returns the value based on the UTC standard.
To get the correct time zone value, you must know the value of the offset at the time of the date (not of the current date).
The problem doesn’t stop here. There is another problem waiting where you won’t get wanted value by simply adding or subtracting offsets.
Therefore Date objects produced using those strings may represent different moments in time depending on the version of ECMAScript supported unless the system is set with a local time zone of UTC. This means that two date strings that appear equivalent may result in two different values depending on the format of the string that is being converted.
It's strange to think that time zones were invented as a way of reducing confusion rather than causing it.
Once upon a time we set the logging for servers in the local time of wherever they were located. This made correlation of events, especially to local computers, consistent and relatively easy. Then the internet was born, and we moved our servers to the cloud and data centers. Suddenly, setting logging to local time made no sense at all.
If you are a small firm and all your administrators and users are in one time zone, logging into that time zone might be more appropriate. If all of the logs are pulled into a central location from various time zones for analysis, you might choose UTC to do a cross analysis.
What is more useful, however, is a definition of time that doesn't vary with location. This is called Universal Time (UT) and is a modern form of Greenwich Mean Time. It is the same everywhere in the Universe.
The most common usage in transport timetables for air, rail, bus, etc. is to use lightface for a.m. times and boldface for p.m. times.
The 24-hour notation is also widely used by astronomers, hospitals, various forms of transportation, and at radio and other broadcast media outlets behind the scenes where scheduling programming needs to be exact, without mistaking AM and PM. In these cases, exact and unambiguous communication of time is critical.
Keep in mind that time zone changes themselves are made at the whim of the world's various governments, and not all changes are made with sufficient notice to make it into these release cycles before their respective effective dates.
It's important to recognize that while an IANA time zone can be mapped to a single Windows time zone, the reverse is not true. A single Windows time zone might be mapped to more than one IANA time zone.
McIlroy nearly missed his singles match that Sunday here at Medinah when he got confused with the time zones.

Something similar

Time zones

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. To make it a bit more complicated, we also have to imagine that within some states the relation will not be the same everywhere.

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 250 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 and our current timekeeping system.

Another view

If you should leave out the unit when measuring weights, lengths or currencies, you should probably be kicked out from your work. A length of 34, a weight of 19 or a monetary amount of 750 are not understandable at all. Compare it to 34 kg, 19 inches and USD 750. Or 34 pounds, 19 cm and SEK 750.

But when it comes to defining times, we accept that people leave the unit. The unit in this case is of course the time zone part of the time value. But it is quite a difference between the following time values:

    2017-12-18 19:20:21
    2017-12-18 19:20:21 Europe/Stockholm
    2017-12-18 19:20:21 Europe/London
    2017-12-18 19:20:21 EET
    2017-12-18 19:20:21 AWST
    2017-12-18 19:20:21 UTC-08:00
    2017-12-18 19:20:21 UTC+03:00

So just writing 2017-12-18 19:20:21 for a timestamp will never be enough. And of course, writing 2017-12-18 19:20:21 (local time) is as bad, as it will be ambiguous and force the reader to investigate further. You would not write "The box weighs 34 (local unit)" or "The price is 50 (local currency)", would you?

Missing informing about DST

Using the abbreviation CET instead of CEST when DST is active in Sweden, is as bad as mixing different units. For example, if you define a timestamp as 2019-04-25 13:30 CET, when you instead actually mean 2019-04-25 13:30 CEST, is like saying 57 yards instead of 57 meters. Or saying 32° Celsius instead 32° Fahrenheit. You will appear as a fool.

AM and PM

Is using AM and PM a good idea? Let us think about it.

Using AM and PM is like dividing each day in two equal parts. Instead of using the markers AM and PM, we could instead use 1/2 and 2/2 respectively, denoting first half and second half. It would be the exact same thing. This results in the following table, where first column contains some random time values in 24-hour notation and where the values in each row represent the same time of day in different notations.

    00:20     12:20 AM     12:20 1/2
    01:55      1:55 AM      1:55 1/2
    06:20      6:20 AM      6:20 1/2
    11:00     11:00 AM     11:00 1/2
    12:05     12:05 PM     12:05 2/2
    15:00      3:00 PM      3:00 2/2
    19:25      7:25 PM      7:25 2/2
    23:10     11:10 PM     11:10 2/2

If dividing the day is a good idea, let us try to divide it even further, since that would be even better. We divide in four, i.e. we use the markers 1/4, 2/4, 3/4 and 4/4. This mean that each part is six hours (instead of 12 hours). Of course, we will use the sequence 6, 1, 2, 3, 4 and 5 to denote the hours, so we follow the same pattern as for the familiar 12-hour clock.

    00:20     12:20 AM     12:20 1/2      6:20 1/4
    01:55      1:55 AM      1:55 1/2      1:55 1/4
    06:20      6:20 AM      6:20 1/2      6:20 2/4
    11:00     11:00 AM     11:00 1/2      5:00 2/4
    12:05     12:05 PM     12:05 2/2      6:05 3/4
    15:00      3:00 PM      3:00 2/2      3:00 3/4
    19:25      7:25 PM      7:25 2/2      1:25 4/4
    23:10     11:10 PM     11:10 2/2      5:10 4/4

So if you now say "Call me tomorrow at three o'clock", I would be even more confused about when that is. Do you still think AM and PM together with the 12-hour clock is a good idea compared to the 24-hour clock?

Date formats

Is using mm/dd/yy or dd/mm/yy as date formats a good idea? Let us think about it.

Using the date formats mm/dd/yy or dd/mm/yy would be like using the time formats mm:ss:hh or ss:mm:hh (instead of hh:mm:ss).

The following table contains rows that represent the exact same time values in different time formats. The rows are sorted increasingly.

    hh:mm:ss    mm:ss:hh    ss:mm:hh
    01:23:45    23:45:01    45:23:01
    05:30:00    30:00:05    00:30:05
    14:15:16    15:16:14    16:15:14
    19:59:59    59:59:19    59:59:19
    20:00:00    00:00:20    00:00:20
    20:00:01    00:01:20    01:00:20
    23:45:01    45:01:23    01:45:23

Note: You would probably have a hard time proving your sanity if you should start to use the mm:ss:hh or ss:mm:hh formats.

Another way of thinking about it could be that you use another format for writing floating point numbers. You can for instance write the decimal part before the integer part. So if I would say that a bag weighs 17.54 kg, you could instead say that it weighs 54.17 kg and we would both mean the same thing.

Do you still think that other date formats than yyyy-mm-dd is a good idea?



World Wide Web Consortium (W3C)

Java API

Mozilla Developer Network (MDN)


Stack Overflow



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 and continuously revised.