Let's say my timezone is America/Chicago. When Daylights Savings Time ends on Nov 1st, the clock will tick from 1:59:59 CDT (UTC -05:00) to 1:00:00 CST (UTC -06:00), if I understand DST correctly.
This means that on Nov 1st, there will be be two instances of the time span 1am to 1:59:59am. When I create an event in Google Calendar on Nov 1st from 1:30am to 1:45am, how does it know which span of 15min I'm referring to?
Naturally, it seems like the way to distinguish between the first instance of 1:30am to 1:45am America/Chicago and the second instance of 1:30am to 1:45am America/Chicago is by associating their respective offset (UTC -05:00 and UTC -06:00, respectively).
The issue is that Google Calendar doesn't seem to deal with offsets, only timezones, but in this case there are two different instances of 1:30am to 1:45am America/Chicago since the America/Chicago has two different offsets (UTC -05:00 DST, UTC -06:00 ST).
Am I missing something, or is this an edge case / UI issue?
Thanks!
This will depend on the user's perspective. As you can see in the documentation:
You can change your time zone and create events in certain time zones. No matter where you create an event, everyone will see it in their own time zone. This can help with travel plans or make it easy to create events for people around the world.
Calendar uses UTC Time Zone, so:
When events are created, they're converted into UTC, but you'll always see them in your local time.
This means your event at -5:00 UTC from 1:30am to 1:45 am will show up at that time, and after the Time Change it will not be there anymore, as the time changes at 1:59:59 after the event has ended.
In the case your event went from 1:50am to "2:15am", with the Time Change it would actually start at -5 UTC 1:50 and end at -6 UTC 1:15.
I have a few queries regarding the Time zones:
Can the time be captured in UTC alone?
Is UTC -6 and GMT -6 the same, and does that mean it is US local time?
Say, I have UTC time as "02-01-2018 00:03" does that mean my US local time is "01-01-2018 18:00"?
I have searched on Wikipedia and many related websites but haven't found a relevant explanation.
Astronomy versus Atomic clock
By the original definitions the difference is that GMT (also officially known as Universal Time (UT), which may be confusing) is based on astronomical observations while UTC is based on atomic clocks. Later GMT has become to be used at least unofficially to refer to UTC, which blurs the distinction somewhat.
GMT stands for Greenwich Mean Time, the mean solar time at the Royal Observatory in Greenwich on the south bank in Eastern London, UK. When the sun is at its highest point exactly above Greenwich, it is 12 noon GMT. Except: The Earth spins slightly unevenly, so 12 noon is defined as the annual average, mean of when the sun is at its highest, its culmination. In GMT there can never be any leap seconds because Earth’s rotation doesn’t leap.
UTC, which stands for Coordinated Universal Time in English, is defined by atomic clocks, but is otherwise the same. In UTC a second always has the same length. Leap seconds are inserted in UTC to keep UTC and GMT from drifting apart. By contrast, in GMT the seconds are stretched as necessary, so in principle they don’t always have the same length.
For roughly 100 years GMT was used as the basis for defining time around the world. Since the world these days mostly bases precise definition of time on atomic clocks, it has become customary to base the definition of time on UTC instead.
Edit: The original meaning of GMT is somewhat useless these days, but the three letter combination doesn’t seem to go away. I take it that it is often used without regard to whether UTC is really intended, so don’t put too much trust into the strict definition given above.
For your questions:
Yes, time can be captured in UTC alone. Storing time in UTC and using UTC for transmitting date-time information is generally considered good practice.
I suppose it’s up to each state of the US to define its time. And I don’t know, but I suppose that today they (officially or in practice) define time as an offset from UTC rather than GMT. The difference between the two will always be less than a second, so for many purposes you will not need to care. Central Standard Time (for example America/Chicago) is at offset -6, as is Mountain Daylight Time (for example America/Denver). On the other hand, offset -6 doesn’t necessarily imply a time in the US. Parts of Canada and Mexico use it too, of course, and also Galapagos and Easter Island.
I don’t think you got your example time exactly right, but yes, 2 January 2018 at 00:00 UTC is the same point in time as 1 January 2018 at 18:00 in Chicago and other places that are at UTC-6 in winter (winter on the Northern hemisphere, that is).
Further reading:
Systems of Time.
Current Millis with a simple and a complex take on UTC vs. GMT.
❌ 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.
Strings
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.
java.time
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.
InstantAlways in UTC. Technically, a count of nanoseconds since the epoch reference of first moment of 1970 (1970-01-01T00:00:00Z).
OffsetDateTimeA date with time-of-day in the context of a certain number of hours-minutes-seconds ahead of, or behind, UTC.
ZonedDateTimeA 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.
Not a moment
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.
UTC
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.
Time zone
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]
Same moment, different wall-clock time
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!
About java.time
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 Stack Overflow 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?
Java SE 8, Java SE 9, Java SE 10, Java SE 11, and later - Part of the standard Java API with a bundled implementation.
Java 9 adds some minor features and fixes.
Java SE 6 and Java SE 7
Most of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
Android
Later versions of Android bundle implementations of the java.time classes.
For earlier Android (<26), the ThreeTenABP project adapts ThreeTen-Backport (mentioned above). See How to use ThreeTenABP….
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.
There is no time difference between Coordinated Universal Time and Greenwich Mean Time.
7:17 AM Friday, Coordinated Universal Time (UTC) is
7:17 AM Friday, Greenwich Mean Time (GMT)
Key difference: Both UTC and GMT are time standards that differ in terms of their derivation and their use.
To quote timeanddate.com:
The Difference Between GMT and UTC:
Greenwich Mean Time (GMT) is often interchanged or confused with
Coordinated Universal Time (UTC). But GMT is a time zone and UTC is a
time standard.
Although GMT and UTC share the same current time in practice, there is
a basic difference between the two:
GMT is a time zone officially used in some European and African countries. The time can be displayed using both the 24-hour format (0 - 24) or the 12-hour format (1 - 12 am/pm).
UTC is not a time zone, but a time standard that is the basis for civil time and time zones worldwide. This means that no country or
territory officially uses UTC as a local time.
GMT is a mean solar time calculated at the Greenwich meridian. https://www.rmg.co.uk/discover/explore/greenwich-mean-time-gmt
UTC is based on the extremely regular "ticking" of caesium atomic clocks. https://en.wikipedia.org/wiki/Coordinated_Universal_Time
They are neither based on the same time nor calculated the same way. IMHO, the wording on https://currentmillis.com is misleading, at best, if not just flat out incorrect.
I have some questions regarding PEP 495.
The classes in the datetime module (well, some of them) now accept a fold argument which value is 0 by default and this value can also be set to 1.
For example, datetime.datetime(..., fold=1).
In my country (Slovenia, Central Europe) we set our time one hour ahead and one hour back between 2 AM and 3 AM. In other countries it's between 1 AM and 2 AM, I think.
1st question: Is this fold smart enough to determine if daylight-saving time is set between 2 AM and 3 AM or if it is set between 1 AM and 2 AM?
2nd question: So setting fold to 1 takes into account the daylight-saving time, right? Is that what it does?
3rd question: Is my understanding of the fold argument even correct?
What is a fold?
A fold is a local time that's ambiguous. This happens whenever the clock is moved back. Take the next time change in Germany as an example:
On the 29th of October 2017 at 3 AM, the clocks will be set back to 2 AM.
Now Imagine that you tell someone that you'd like to meet on Oct 29th 2017 at 2:30 AM. Do you mean before or after the time change happened? It's ambiguous because there are two points in time where the clocks show this exact time.
The fold attribute that PEP 495 adds provides exactly that information. It's 0 for the time before the time change and 1 for the time after it.
This is how it is described in PEP 495:
This PEP adds a new attribute fold to instances of the datetime.time and datetime.datetime classes that can be used to differentiate between two moments in time for which local times are the same. The allowed values for the fold attribute will be 0 and 1 with 0 corresponding to the earlier and 1 to the later of the two possible readings of an ambiguous local time.
Daylight saving time and datetime objects
From the python datetime docs:
There are two kinds of date and time objects: “naive” and “aware”.
An aware object has sufficient knowledge of applicable algorithmic and political time adjustments, such as time zone and daylight saving time information, to locate itself relative to other aware objects. An aware object is used to represent a specific moment in time that is not open to interpretation [1].
A naive object does not contain enough information to unambiguously locate itself relative to other date/time objects. Whether a naive object represents Coordinated Universal Time (UTC), local time, or time in some other timezone is purely up to the program, just like it is up to the program whether a particular number represents metres, miles, or mass. Naive objects are easy to understand and to work with, at the cost of ignoring some aspects of reality.
For applications requiring aware objects, datetime and time objects have an optional time zone information attribute, tzinfo, that can be set to an instance of a subclass of the abstract tzinfo class. These tzinfo objects capture information about the offset from UTC time, the time zone name, and whether Daylight Saving Time is in effect. Note that only one concrete tzinfo class, the timezone class, is supplied by the datetime module. The timezone class can represent simple timezones with fixed offset from UTC, such as UTC itself or North American EST and EDT timezones. Supporting timezones at deeper levels of detail is up to the application. The rules for time adjustment across the world are more political than rational, change frequently, and there is no standard suitable for every application aside from UTC.
TL;DR:
The standard library provides:
Unambiguous local times (using the fold argument for times that would otherwise be ambiguous).
An tzinfo attribute for datetime objects that can be used to implement time zone and daylight saving time information.
The standard library does not provide:
Time conversion between different time zones that is aware of daylight saving time.
Answering your questions
Is this fold smart enough to determine if daylight-saving time is set between 2 AM and 3 AM or if it is set between 1 AM and 2 AM?
No, it's not, not even the python standard library provides this. I'm sure that there are third-party libraries that can do this, but I haven't used any of them until now.
So setting fold to 1 takes into account the daylight-saving time, right? Is that what it does?
Not really. The meaning of the fold argument is more like "is this the first or the second time that the clock displays this time". You only need this argument for the (usually) one hour where the clocks are moved back. Except from this case, local time is unambiguous, so you don't need the fold argument. Whether or not it's daylight saving time isn't relevant for the argument.
Is my understanding of the fold argument even correct?
Not really, but I hope that I could shed some light with my answers above.
As we know, when ever our clocks go 1h back (as they did on 29OCT at 2:00 in some countries) ending the DST period, every timestamp between 1:00 and 2:00 'occurs' twice.
How should an application working with future events handle this?
For example user creates a future event and specifies that it will take a place on 29OCT at 1:35.
And let's assume that standard local time is UTC+3 and the DST is UTC+4
How should the application convert this time to UTC? Should this time be considered as the first instance (before end of DST, which makes it 21:35 UTC) or the second instance (after end of DST, i.e. 22:35 UTC)?
Only you can decide that. It is largely based on context.
In many cases, the right thing to do is to choose the first of the two occurrences - which would be the daylight time. In your example, it would run at 1:35 in UTC+4.
You also need to consider the spring-forward transition. A recurring task that falls into the gap should usually be displaced by an amount equal to the DST bias (which is usually 1 hour). For example, if the clock jumps from 1:59:59.999 to 3:00, then a task scheduled to run at 2:30 would run at 3:30 on that day.
Again, only you can decide what is the right behavior for your application. Some applications may need the fall event to run at the standard time, or at both times. In the spring, they may want to run at the very next instant past the gap (3:00 in the above example, instead of 3:30) - or they may not want to run at all.
See also:
The DST Tag Wiki
How to store repeating dates keeping in mind Daylight Savings Time
Correct way to calculate recurring dates in C#
java Calendar, Date, and Time management for a multi-timezone application
Scheduled Jobs during hours of autumn time change
Given the discontinuity in timezones, is there a standard method of specifying which of two repeated clock times you are interested in? This came to my attention from a Java discussion "Why is subtracting these two times (in 1927) giving a strange result?", that was recently brought up, but this is not isolated to strange events in China in the 1920's.
How do I tell you which 01:50 AM (EST) I am interested in on November 3rd this year? I know that I could use UTC, epoch time... but is there even a good way to ask a user which local time they are interested in?
How do I tell you which 01:50 AM (EST) I am interested in on November 3rd this year?
By qualifying it as EST, you are already specifying that you mean "Eastern Standard Time" which is UTC-05:00. That is the second instance of 1:50am. The first instance occurred in "Eastern Daylight Time" (EDT) which is UTC-04:00. Of course, had you just said "Eastern Time", then I wouldn't know which one you meant.
However - keep in mind that "EST" by itself is not unique. I made a guess that you meant Eastern Standard Time in the USA - but you could have meant one of three different zones all called the same thing. See here for a list of time zone abbreviations. Now it happens to be that all "EST" zones are in UTC-05:00, but that is just coincidence. There are several zones that have the same name or abbreviation and have different offsets or different DST start/stop dates.
The "standard" you are looking for is part of ISO8601, which allows for dates and times to include an offset. For example, the two points mentioned would be:
2013-11-03T01:50:00-04:00
2013-11-03T01:50:00-05:00
Keep in mind that the offset uniquely identifies the moment/instant in time - but it it does not uniquely identify a time zone. There are several other time zones that use the -04:00 and -05:00 offsets at different times. This point is often forgotten, because the offset is sometimes referred to as the "zone" erroneously.