Why is UTC (which is not a time zone) considered a time zone in Java (and not only there)?

Question

Given that UTC is not a time zone, but a time standard (as indicated, for example, here ), why in my Java can I use UTC as if it were a time zone (see the code snippet below)?

SimpleDateFormat format = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"); format.setTimeZone(TimeZone.getTimeZone("UTC")); 

If UTC is not a time zone, why can TimeZone.getTimeZone("UTC") return a time zone object?

---

By the way, on my Windows machine, UTC is also in the list of time zones (see screenshot).

Is the UTC non-timezone statement really wrong?

Answer 1

Is the UTC non-timezone statement really wrong?

Technically and, strictly speaking, the statement is incorrect. UTC is a standard, not a time zone (as you have already linked).

The time zone corresponds to some area in the world and has many different rules regarding this region:

• What UTC biases (unlike UTC) when it is in daylight saving time and when it is not
• When does DST begin and end
• All changes in offsets and DST in this region have been in history.

Example: in 1985, the Brazilian state of Acre had a standard offset of UTC-05:00 (and UTC-04:00 during DST), then in 1988 it was at UTC-05:00 without DST, then in 2008 the standard changed to UTC-04:00 (and there is no DST), and since 2013 it returns to UTC-05:00 and does not have DST.

As long as the time zone keeps track of all these changes, UTC does not have such rules. You can think of UTC differently:

• The "base" date / time, whence all the others relate to this - this difference from UTC is called "offset". Today, São Paulo is at UTC-03:00 (offset minus 3 hours , or 3 hours behind UTC), while Tokyo is at UTC+09:00 (offset plus 9 hours , or 9 hours ahead of UTC) .
• A “special” time zone that never changes. It is always at the same offset (zero), it never changes and never shifts the DST.

Since the “UTC bias” (not sure how technically accurate the term is) is always zero, usually UTC+00:00 or just Z for recording.

Another difference between UTC and the time zone is that the time zone is determined by governments and laws and can change anytime, anywhere. All the changes in Acre described above were determined by politicians for one reason or another, which they thought at that time. (So, even if a region today follows UTC in its time zone, there is no guarantee that it will remain unchanged in the future, and why even those regions have their own time intervals, even if they look redundant). A.

But no matter how many times politicians change their biases in the regions, they should relate to UTC ( until a new standard appears , of course).

---

Now that you see implementations like TimeZone.getTimeZone("UTC") , you can think about it in two different ways:

• design flaw as it mixes 2 different concepts and allows people to think that they are one and the same.
• shortcut / simplification / good trick / workaround, which simplifies the job (as @JonSkeet explains in his answer ).

For me, this is a mixture of both (fifty / fifty).

---

The new java.time API , however, shares the concepts in 2 classes: ZoneRegion and ZoneOffset (in fact, both are subclasses of ZoneId , but ZoneRegion not public, so we use ZoneId and ZoneOffset ):

• if you use ZoneId with IANA time zone names (always in Continent/City format, for example America/Sao_Paulo or Europe/Berlin ), it will create a ZoneRegion object - a “real” time zone with all DST rules and offset during its history. Thus, you may have different offsets depending on the dates with which you work in this ZoneId .
• If you use ZoneOffset (with Z , UTC , +03:00 , etc.), it only returns an object representing the offset: unlike UTC, but without any DST rules. No matter what date you use this object, it will always have the same difference with UTC.

So, ZoneId (actually ZoneRegion ) is consistent with the idea that offsets in a certain area (in a certain time zone ) change over time (due to DST rules, politicians change things because anything, etc.). And ZoneOffset represents the idea of ​​being different from UTC , which has no DST rules and never changes.

And there is a special constant ZoneOffset.UTC , which is a zero difference from UTC (this is UTC itself). Note that the new API takes a different approach: instead of saying that everything is a time zone and UTC is a special type, it says that UTC is ZoneOffset , which has a value of 0 for offset.

You can still consider this a “wrong” design decision or a simplification that simplifies (or mixes both). IMO, this solution was a big improvement over the old java.util.TimeZone , as it clearly shows that UTC is not a time zone (in the sense that it has no DST rules and never changes), it is just a null difference from UTC (a very technical way of saying "this is UTC").

And he also shares the concepts of time zone and bias (these are not the same thing, although they are very related to each other). I see that he defines UTC as a special bias as an “implementation detail”. Creating another class to handle UTC would be redundant and confusing, and saving it as ZoneOffset would be a good solution that would simplify and not spoil the API (for me, a fair compromise).

I believe that many other systems take similar approaches (which explains why Windows has UTC in the list of time zones).

Answer 2

Because it makes life a lot simpler and easier to consider UTC as a time zone than basically consider it as something else.

This is one of those “Yes, strictly speaking, no” scenarios. For everything except "What region of the world is this observed?" you can think of UTC as a time zone, and it works great. Therefore, it is easier to bend it a little in shape than to have a whole separate concept.

If you look at a time zone as a comparison from a point in time to “UTC offset” (or the equivalent, from a “point in time” to a “locally observed time”), then UTC is great to think of as a time zone - and that’s most of what we do in software framework.

If you view the time zone as a geographic region with this mapping, then no, it does not work, but it is rarely used in software. (And you can always fake it by saying that this is an empty area :)