I've a epoch time it's seconds or milliseconds format. How do I get time zone and day light saving details from that epoch time? Or do I have to pass as a separate value?
An epoch time in second or millisecond resolution is just a number. And a number cannot hold more than ONE information, here the elapsed time since an epoch.
Time zone or daylight saving details must therefore be transmitted as extra information. Keep also in mind that a time zone is often pretty complex (has an ID, a name, a history of offset transitions etc.) so most time zones cannot just be expressed as simple numbers.
By the way, I cannot give more concrete answer how to transmit extra details like time zones since you have not even told us which programming language or tool you use.
Related
What is the definition of Daylight Savings Time 'Overlap' & 'Gap'?
I have a hazy understanding of them, so I'd like to confirm... What does it mean to be "within" either of them?
What does it mean to "correct" for DST Gap or DST Overlap? When does a time need correcting, and when does it not need correcting?
The above questions are language-agnostic, but an example of their application I have is:
When to call org.joda.time.LocalDateTime#correctDstTransition?
Correct date in case of DST overlap.The Date object created has
exactly the same fields as this date-time, except when the time would
be invalid due to a daylight savings gap. In that case, the time will
be set to the earliest valid time after the gap. In the case of a
daylight savings overlap, the earlier instant is selected.
Much of this is already explained in the DST tag wiki, but I will answer your specific questions.
What is the definition of Daylight Savings Time 'Overlap' & 'Gap'?
...
What does it mean to be "within" either of them?
When daylight saving time begins, the local time is advanced - usually by one hour. This creates a "gap" in the values of local time in that time zone.
For example, when DST starts in the United States, the clocks tick from 1:59 AM to 3:00 AM. Any local time value from 2:00 AM through 2:59 AM would be considered to be "within the gap".
Note that values in the gap are non-existent. They do not occur in the real world, unless a clock was not correctly advanced. In practice, one typically gets to a value within the gap by adding or subtracting an elapsed time value from another local time.
When daylight saving time ends, the local time is retracted by the same amount that was added when it began (again, usually 1 hour). This creates an "overlap" in the local time values of that time zone.
For example, when DST ends in the United states, the clocks tick from 1:59 AM back to 1:00 AM. Any local time value from 1:00 AM through 1:59 AM is ambiguous if there is no additional qualifying information.
To be "within the overlap" means that you have a value that is potentially ambiguous because it falls into this range.
Such values may belong to the daylight time occurrence (which comes first sequentially), or may belong to the standard time occurrence (which comes second sequentially).
What does it mean to "correct" for DST Gap or DST Overlap?
Correcting for the gap means to ensure that the local time value is valid by possible moving it to a different value. There are various schemes in use for doing so, but the most common and most sensible is to advance the local time value by the amount of the gap.
For example, if you have a local time of 2:30 AM, and you determine it to occur on the day of the spring-forward transition in the United States, then it falls into the gap. Advance it to 3:30 AM.
This approach tends to work well because simulates the act of a human manually advancing an analog clock - or rather, correcting with the idea that it had not been properly advanced.
Correcting for the overlap means to ensure that all local times are well qualified. Usually this is accomplished by assigning a time zone offset to all values.
In the case of a value that is not ambiguous, the offset is deterministic.
In the case of a value that falls within the overlap on the day of a fall-back transition, it often makes sense to choose the first of the two possible values (which will have the daylight time offset). This is because time moves in a forward direction. However, there are sometimes cases where it makes sense to use a different rule, so YMMV.
When does a time need correcting, and when does it not need correcting?
If you are attempting to work with time as an instantaneous value, such as determining the elapsed duration between two values, adding an elapsed time to a specific value, or when converting to UTC, then you need to correct for gaps and overlaps as they occur.
If you are only working with user input and output, always displaying the exact value a user gave you (and never using it for math or time zone conversions) then you do not need to correct for gaps and overlaps.
Also, if you are working with date-only values, or time-only values, then you should not be applying time zone information at all, and thus do not need to correct for gaps and overlaps.
Lastly, if you are working strictly with Coordinated Universal Time (UTC), which has no daylight saving time, then you do not need to correct for gaps and overlaps.
When to call org.joda.time.LocalDateTime#correctDstTransition?
You don't. That method is private, and is called by other Joda-time functions as needed.
I'm reverse engineering a query from a kibana board and it has timestamp values in it like '1408884022624'.
In reading over the elastic search date mapping docs I don't see anything in there regarding what (appears to be) some sort of millisecond or tick format. Could someone tell me what the number above represents in my query? (I'm pretty sure we're not using a custom date format.)
It's the number of milliseconds since the beginning of Unix Epoch time, 00:00:00 UTC January 1 1970. Sometimes referred to as Java Epoch time. Technically it's not Unix Epoch time as that's tracked as the number of seconds since the above date, but many tools/converters handle both seconds and milliseconds.
Care should be taken, though, as it's quite easy to accidentally get the time in one format (let's say seconds) and pass it to a function or method expecting it in the other.
http://en.wikipedia.org/wiki/Unix_time
http://www.javaworld.com/article/2074293/core-java/groovy--java--and-the-unix-epoch-time.html
I am planning on starting a project that will need to record timestamps of incoming transactions. I appreciate that Unix Time is an integer value and I can use this type of functionality to my advantage. However, Unix Time only measures in seconds. As a minimal requirement I need to record transaction times at the millisecond level.
I know that there are ways that I could get around this issue, but I was wondering if there was another standardized way of representing time data that also represented milliseconds (or, some factor of sub-milliseconds) in the time value that is fully expressed as an integer value since epoch.
Does such a time format exist? FYI, so long as the date data-type is standardized, I don't care what system this is native in. I can code my own implementation, however, I would like to use an existing date/time format, rather than create my own.
One place where such a standard is used is ECMAScript / Javascript. Javascript date objects use milliseconds since January 1, 1970, midnight UTC for their numerical integer representation. This is detailed here.
You can test this using your browser's console:
var d = new Date();
console.log(d.getTime()); // yields integer milliseconds since epoch
So yes, there is prior art for such a use.
date +%s
outputs timestamp in seconds
date +%s%N
returns timestamp in nanoseconds
To get milliseconds divide the nanoseconds by 1 000 000
UNIX time is not appropriate for time stamping transactions because it does some weird stuff, inserting leap seconds on occasion, thus making it so that you won't be able to add and subtract time stamps reliably, nor sort transactions by timestamp.
A more appropriate standard for timestamps is TAI https://www.nist.gov/pml/time-and-frequency-division/nist-time-frequently-asked-questions-faq#tai . TAI is stored in the same way as UNIX time as a number of seconds and or microseconds and or nanoseconds since the UNIX epoch, however, it is the true number, no leap seconds are added or removed. This means that you can actually add and subtract TAI timestamps to get elapsed time and TAI timestamps are always sortable. Unfortunately, support for TAI timestamps is somewhat limited. For example, linux added support for TAI timestamps only recently in version 3.10 python added this support only in version 3.9/time.html?highlight=time#module-time
I understand that it's pretty easy to display local time to a user given an offset from GMT for the timezone (e.g. -7 hours for Pacific Daylight Time).
But, what if I want to continue to display the correct local time for a long period of time (say 1 year). Given just an offset from GMT, you do not know what timezone the user is in. E.g. given -7, the user may live in the US or in Canada (or in some other country). These countries my have different local times at different points of the year (e.g. if the US changes to daylight time in March and CA in April).
My question is, is the above paragraph correct? Is there a standard way to take a GMT offset and make a good guess as to which timezone the user is in?
Your conclusion is correct: There is no reliable way to identify a time zone from an offset-from-UTC.
For your example of an offset of -07:00, I count about three dozen possible time zones in the current list including: America/Boise, America/Chihuahua, and America/Edmonton.
A time zone is actually a collection of offsets, recording changes made over time with a certain offset used in that region for a certain period of time but then changed over another certain period of time.
For example, in America/Los_Angeles part of each year has an offset of -08:00 while another part of the year has -07:00. So that time zone is accumulating a history of at least two offsets per annum. In contrast, the neighboring region using the time zone America/Phoenix is not accumulating changes in its offset, having retained the same -07:00 offset for decades.
So we have a many-to-many relationship between offsets and time zones. An offset may appear in one or more time zones. And each time zone can have one or more offsets (having changed over history).
Include time zone name
This is why the designers of the java.time class ZonedDateTime have taken the liberty of having its toString method extend the standard ISO 8601 format using only offsets to also append the name of the time zone in square brackets.
For example, instead of simply generating the standard format: 2007-12-03T10:15:30+01:00, the class generates 2007-12-03T10:15:30+01:00[Europe/Paris] with the name of the zone Europe/Paris appended.
ZonedDateTime.now( ZoneId.of( "America/Montreal" ) )
.toString()
2007-12-03T10:15:30+01:00[Europe/Paris]
I hope this practice of appending the time zone name catches on. The lack of time zone name is a surprising omission by the standards committees that otherwise did an outstanding job in designing ISO 8601.
You can guess about the time zone using clues from the context of your business scenario. But I advise against that. Guessing is risky, especially because politicians around the world have a penchant for frequently re-defining time zones.
UTC
The best practice in storing, serializing, and exchanging date-time values is generally to adjust into UTC. Assuming a date-time library’s tzdata is up-to-date, adjusting into UTC provides a reliable value that is always correct and unambiguous.
In Java, for example, that means using or extracting an Instant object. The Instant class represents a moment on the timeline in UTC with a resolution of nanoseconds (up to nine (9) digits of a decimal fraction).
Instant instant = Instant.now();
…or…
ZonedDateTime zdt = ZonedDateTime.now( ZoneId.of( "America/Montreal" ) );
Instant instant = zdt.toInstant();
The standard ISO 8601 formatted string representing such a value uses a Z as short for Zulu and meaning UTC.
2007-12-03T09:15:30Z
OffsetDateTime
If you are given a string representing a date-time with only an offset, parse it as a OffsetDateTime object.
OffsetDateTime odt = OffsetDateTime.parse( "2007-12-03T10:15:30+01:00" );
odt.toString(): 2007-12-03T10:15:30+01:00
From there you can extract a value in UTC, an Instant.
Instant instant = odt.toInstant();
instant.toString(): 2007-12-03T09:15:30Z
Or you can adjust into a desired time zone to get the same moment as a ZonedDateTime object.
ZoneId z = ZoneId.of( "Asia/Kolkata" );
ZonedDateTime zdt = odt.atZoneSameInstant( z );
zdt.toString(): 2007-12-03T14:45:30+05:30[Asia/Kolkata]
Terminology: “local”
I suggest you avoid the term “local” when referring to a date-time adjusted into a region’s particular wall-clock time. The word “local” in the java.time classes and in other contexts means any locality, rather than a particular locality. A local date-time is not a specific moment on the timeline, only a rough idea about a range of possible moments.
For example the local date-time of the beginning of Christmas this year is 2017-12-25T00:00:00, but that moment of midnight is much earlier in Auckland than in Kolkata, and still hours later in Paris, while even more hours later in Montréal.
I suggest instead you use the terms zoned or wall-clock time when you mean a specific moment seen through the lens of a particular time zone.
Tip: Offset literals
The Question happened to use the letters -7 when referring to an offset. I suggest always:
Using double-digits with padding zero, as required by ISO 8601
Using both hour and minutes, as expected by some libraries and formats.
So use -07:00 rather than -7.
Is the timezone difference always ignored, regardless in which zone the time is expressed in?
Intuitively, the number of seconds passed since EPOCH should be higher for those who are, for example, in UTC+2. However, this seems not to be the case.
Epoch is based on the utc timezone https://en.wikipedia.org/wiki/Unix_time
it does not depend of the timezone you're currently in.