❌ The accepted Answer is neither correct nor useful.
✅ In contrast, the Answer by Ole V.V. correctly summarizes the technical differences — for details follow the links to detailed pages in Wikipedia.
For programmers building business-oriented apps, the upshot is that UTC is the new GMT. You can use the terms interchangeably, with the difference being literally less than a second. So for all practical purposes in most apps, no difference at all.
Here is some more practical advice, with code examples.
Say, I have UTC time as "02-01-2018 00:03" does that mean my US local time is "01-01-2018 18:00"?
That first part is a bad example, with the date-time string lacking an indicator of its offset or zone.
If a string indicates a specific moment, it must indicate either a time zone (Continent/Region formatted name) and/or an offset-from-UTC as a number of hours-minutes-seconds. If the string is meant to represent a moment at UTC itself, that means an offset-from-UTC of zero.
To write that string with an offset, various conventions may be applied. The best in practice is with both hours and minutes along with a colon, such as +00:00, +05:30, or -08:00. The leading zero and the colon are both optional but I have seen libraries break when encountering a value such as -0800 or -8.
Zulu
As a shortcut for an offset of zero, the letter Z is commonly used to mean UTC itself. Pronounced Zulu.
ISO 8601
Furthermore, best practice in formatting date-time textually for computing is to us the ISO 8601 standard formats. For a date-time the format YYYY-MM-DDTHH:MM:SS±HH:MM:SS is used. The T separates the date portion from the time-of-day portion. This format has advantages such as being largely unambiguous, easy to parse by machine, easy to read by humans across cultures. Another advantage is sorting alphabetically is also chronological. The standard accepts the Z abbreviation as well.
So your example UTC time as "02-01-2018 00:03" is better stated as 2018-01-02T00:03Z.
Be very aware that most programming languages, libraries, and databases have very poor support for date-time handling, usually based on a poor understanding of date-time issues. Handling date-time is surprisingly complicated and tricky to master.
The only decent library I have encountered is the java.time classes (see Tutorial) bundled with Java 8 and later, and its predecessor the Joda-Time project (also loosely ported from Java to .Net in the Noda Time project).
In java.time, a moment is represent in three ways. All have a resolution of nanoseconds.
Instant
Always in UTC. Technically, a count of nanoseconds since the epoch reference of first moment of 1970 (1970-01-01T00:00:00Z).OffsetDateTime
A date with time-of-day in the context of a certain number of hours-minutes-seconds ahead of, or behind, UTC.ZonedDateTime
A date with time-of-day in the context of a certain time zone.
So what is the difference between a time zone and an offset-from-UTC? Why do we need separate classes? An offset-from-UTC is simply a number of hours-minutes-seconds, three numbers, no more, no less. A time zone in much more. A time zone is a history of the past, present, and future changes to the offset used by the people of a particular region.
What changes? Changes dictated by the whims or wisdom of their politicians. Politicians around the world have shown a predilection for changing the offset used by the time zone(s) in their jurisdiction. Daylight Saving Time (DST) is one common pattern of changes, with its schedule often changed and the decision to enact or revert from DST sometimes changed. Other changes happen too, such as just in the last few years North Korea changing their clock by half-an-hour to sync with South Korea, Venezuela turning back their clock half-an-hour only to jump back forward less than a decade later, Turkey this year canceled the scheduled change from DST to standard time with little forewarning, and contemporary Russia having made multiple such changes in recent years.
Back to your example in your point # 3, let's look at some code.
Say, I have UTC time as "02-01-2018 00:03" does that mean my US local time is "01-01-2018 18:00"?
Your example strings have another problem. That 03 minute in the first part is ignored your second part, an apparent typo. I know because there is no time zone adjustment in effect in the Americas on that date involving a fractional hour of 57 minutes.
First, we parse your input string. Lacking any indicator of zone or offset, we must parse using the LocalDateTime. The name LocalDateTime may be misleading, as it does mean a specific locality. It means any or all localities. For more explanation, see What's the difference between Instant and LocalDateTime?.
String input = "2018-01-02T00:03" ; // Text of a date with time-of-day but without any context of time zore or offset-from-UTC. *Not* a moment, *not* a point on the timeline.
LocalDateTime ldt = LocalDateTime.parse( input ) ; // Parsing the input as a `LocalDateTime`, a class representing a date with time but no zone/offset. Again, this does *not* represent a moment, is *not* a point on the timeline.
By the facts given in the Question, we know this date and time was intended to represent a moment in UTC. So we can assign the context of an offset-from-UTC of zero hours-minutes-seconds for UTC itself. We apply a ZoneOffset constant UTC to get a OffsetDateTime object.
OffsetDateTime odt = ldt.atOffset( ZoneOffset.UTC ); // We are certain this text was intended to represent a moment in UTC. So correct the faulty text input by assigning the context of an offset of zero, for UTC itself.
The Question asks to see this moment through a wall-clock time of six hours behind UTC used in the United States. One time zone with such an offset is America/Chicago.
Specify a proper time zone name in the format of continent/region, such as America/Montreal, Africa/Casablanca, or Pacific/Auckland. Never use the 2-4 letter abbreviation such as CST, EST, or IST as they are not true time zones, not standardized, and not even unique(!).
ZoneId z = ZoneId.of( "America/Chicago" ) ; // Adjust from UTC to a time zone where the wall-clock time is six hours behind UTC.
ZonedDateTime zdt = odt.atZoneSameInstant( z ) ;
See this code run live at IdeOne.com.
odt.toString(): 2018-01-02T00:03Z
zdt.toString(): 2018-01-01T18:03-06:00[America/Chicago]
This odt and zdt both represent the same simultaneous moment, the same point on the timeline. The only difference is the wall-clock time.
Let's work an example, using Iceland where their time zone uses an offset-from-UTC of zero hours-minutes-seconds. So the zone Atlantic/Reykjavik has a wall-clock time identical to UTC. At least currently today their wall-clock time matches UTC; in the past or future it may be different, which is why it is incorrect to say “UTC is the time zone of Iceland”. Anyway, our example… say someone in Reykjavík, Iceland with 3 minutes after midnight on the clock hanging on their wall makes a phone call to someone in the US. That US person lives in a place using the Chicago region time zone. As the person called picks up their phone, they glance up at the clock hanging on their wall to see the time is just after 6 PM (18:03). Same moment, different wall-clock time.
Also, the calendars hanging on their walls are different, as it is “tomorrow” in Iceland but “yesterday” in mainland US. Same moment, different dates!
The java.time framework is built into Java 8 and later. These classes supplant the troublesome old legacy date-time classes such as java.util.Date, Calendar, & SimpleDateFormat.
The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.
To learn more, see the Oracle Tutorial. And search for many examples and explanations. Specification is JSR 310.
You may exchange java.time objects directly with your database. Use a JDBC driver compliant with JDBC 4.2 or later. No need for strings, no need for java.sql.* classes.
Where to obtain the java.time classes?
The ThreeTen-Extra project extends java.time with additional classes. This project is a proving ground for possible future additions to java.time. You may find some useful classes here such as Interval, YearWeek, YearQuarter, and more.
No comments:
Post a Comment