Unix time is useful for measuring time, whereas other formats are more useful for telling the time.
This is because (apart from time synchronization), it just ticks forward one second at a time.
It doesn't change when our clock for telling the time has an hour change, for example.
However, there does seem to be one exception. It ignores leap seconds, meaning when there is a leap second, it basically jumps back a second.
I'm wondering is there a similar format to Unix time that also includes leap seconds and has no special cases at all?
Nevermind, unix time has no exception for leap seconds.
I believe the explanation for unix time on Wikipedia is awful:
It is the number of seconds that have elapsed since the Unix epoch, minus leap seconds
This is incorrect, it should be:
It is the number of clock / artificial Earth seconds that have elapsed since the Unix epoch, minus leap seconds
Or in simpler terms:
It is the numbers of measured seconds that have elapsed since the Unix epoch
Hope this solves anyone else's confusion.
Related
RFC 5545 and other standards like JSCalendar define a P1DT12H duration as one nominal day plus 12 exact hours. Normally this will be 36 real-world ("exact" or "accurate") hours, but:
If a Spring DST transition happens during the "one nominal day" part of that duration, then the accurate duration will be only 35 hours.
If a Fall DST transition happens during the "one nominal day" part, then the accurate duration will be 37 hours.
But what if the starting date/time is exactly one nominal day before a discontinuous period? For example, a P1DT12H duration added to 2020-03-07T02:30 in America/Los_Angeles where DST starts at 2020-03-08T02:00. In that case, what should be the calculated local time at the end of that duration?
Is it 2020-03-08T14:30? 2020-03-08T13:30? 2020-03-08T15:30? Something else? Also: why?
The problem is that the naive way of calculating the exact duration would be to add the date portion of the duration using nominal units, then convert that intermediate result to UTC and add the time portion of the duration using exact time. But that intermediate result is an invalid nominal time that's skipped, then the local time of that intermediate value is 2020-03-08T03:30 (3:30AM, not 2:30AM) because RFC 5545 says:
If the local time described does not occur (when changing from standard to daylight time), the DATE-TIME value is interpreted using the UTC offset before the gap in local times.
So using that interpretation of the spec, the final result after adding the 12-exact-hour time portion should be 2020-03-08T15:30 or 3:30PM.
Is this the "correct" answer according to RFC 5455? If not, what should be the answer and why?
Or is this an ambiguity in the standard and there's no objectively correct answer?
I was hoping someone else would answer. Here is my understanding:
Two concepts here:
Either one has the DTEND and is calculating the DURATION, which as you have established, will vary if there is daylight saving change during the event, OR
one has the duration and is calculating the DTEND. It is best to do that in UTC for safety sake.
RE your question:
But what if the starting date/time is exactly one nominal day before a discontinuous period? In that case, what should be the calculated local time at the end of that duration?
For calculating DTEND, nominal day at same time takes us to invalid time. If one uses UTC to calc that nominal day, one gets 3.30 am. The spec says:
In the case of discontinuities in the time scale, such as the change
from standard time to daylight time and back, the computation of the
exact duration requires the subtraction or addition of the change of
duration of the discontinuity.
I understand this to mean yes, when working out the CALCULATED duration (ie where you have DTSTART and DTEND) will vary depending in the events point in the calendar, as you have noted.
RE your question
But that intermediate result is an invalid nominal time that's skipped, then the local time of that intermediate value is 2020-03-08T03:30 (3:30AM, not 2:30AM...."
Yes, however in calculating further I think you went wrong adding the 12H to the local time. Spec says use the earlier UTC offset, which I take to mean use that to get UTC time, use UTC for the calcs, then convert back.
If the local time described does not occur (when changing from
standard to daylight time), the DATE-TIME value is interpreted using
the UTC offset before the gap in local times.
Note this is the UTC offset. So one nominal day takes us to 2.30am which does not 'exist' in LA on 8 March, so we use the UTC offset before the time gap. -8 hours which gives us UTC=10h30.
Plus 12H gives us UTC 22H30.
If we stay with the -8 offset for calculation purposes, we get local time 14:30.
*It is not 100% spelled out in the specification that this is it. More worked examples to confirm would be good.
Advice I have seen elsewhere is to store times in UTC time, do the calcs in UTC time, then for display, calculate local time.*
RE:
Is it 2020-03-08T14:30?
Is this the "correct" answer according to RFC 5455? If not, what should be the answer and why?
I understand it to be 14H30. I cross checked using PHP, with calcs in LosAngeles and in UTC time before DST & during DST, using both datetime->add https://www.php.net/manual/en/datetime.add.php and https://www.php.net/manual/en/datetime.modify.php and consistently got that answer.
I think correct is 2020-03-08T14:30 because if one uses the UTC offset as specified and calcs in UTC, that is what one gets.
PHP Workings
add a nominal day P01D
Before DST:
2020-03-06T02:30:00-08:00
2020-03-07T02:30:00-08:00 with modify
2020-03-07T02:30:00-08:00 add date interval
Over DST:
2020-03-07T02:30:00-08:00
2020-03-08T03:30:00-07:00 with modify
2020-03-08T03:30:00-07:00 add date interval
add a nominal day plus 12 H ie: P01DT12H
Before DST:
2020-03-06T02:30:00-08:00
2020-03-07T14:30:00-08:00 add date interval
Over DST:
2020-03-07T02:30:00-08:00
2020-03-08T14:30:00-07:00 with modify
2020-03-08T14:30:00-07:00 add date interval
For checking offset: https://www.timeanddate.com/worldclock/meetingtime.html?day=8&month=3&year=2020&p1=137&iv=0
Consider a machine whose time is smeared during a leap second with a noon-to-noon linear smear.
I'm wondering how the system clock provides accurate Epoch time during the smear period.
Example:
The leap second is scheduled at 31st dec of 2016.
On the machine, a Unix timestamp at 11:59:00 on 31st of December is 1483185540
At noon the smearing starts, which means the local clock of the system at 1:30 pm is already a few microseconds behind TAI and UTC. The Epoch timestamp should be 1483191000 (exactly 1 hour 31 minutes later), which is not accurate to TAI/UTC anymore since Epoch doesn't respect leap seconds
At 12pm UTC adds an extra second: 11:59:60 pm, the local smeared clock should continue normally
Till, at noon 1st of January global UTC and local UTC sync up again, the local Epoch clock is now an entire second behind global Epoch/TAI
How is this inaccuracy resolved? Does the local Epoch time skip a second once the system knows a leap second happened? Or how is this issue handled?
Does it depend on the implementation of the clock used to calculate the time? If so, how does GNU's coreutils date handle this?
The inaccuracy is not resolved. The Unix Time remains a count of seconds since 1970-01-01 00:00:00 UTC excluding the inserted leap seconds. This has the benefit of making the count of seconds easy to convert to {year, month, day, hour, minute, second} form.
It has the problem that the subtraction of two Unix Time time points that straddle a leap second insertion will result in a time duration that is one second less than reality.
I've recently learned that NTP implements handling of leap seconds. I was really surprised, as I know that NTP stores time as just amount of seconds since January 1, 1900. Shouldn't the issue of leap seconds only be addressed during formatting of the date to human-readable form, as it is the case with leap years?
How can I calculate the number of hours between two times, taking into account the change from standard to daylight savings time between them?
I need to determine which crew is working in my customer's plant. There are four possibilities, changing in a known order from one to the next every four days, so the crew pattern recurs every 16 days. I had planned to store a reference time in my database. To calculate the crew, I would calculate the elapsed hours between the reference time and the current time, modulo it by 384, and use crew A if the result is below 96, crew B for 96-192, and so on.
I am pretty sure that in the spring, when an hour is repeated at the time change, the crew shift is 13 hours long, and in the fall, the crew shift is only 11 hours long. My scheme, at least if it relied on timestamp with time zone objects, would be wrong for an hour every shift for half the year.
Thank you.
Leap seconds are added to correct for variations in the Earth's rotation. However, unlike leap years these do not occur at regular intervals (because it is not due to a systematic error, like leap years).
How are leap seconds handled by systems that use unix timestamps? Are leap seconds hard-coded into updates of programming languages that implement timestamps?
Update: looks like Unix timestamps don't deal with leap seconds
It is handled in the time server, not in the programming languages per se. If a second is being lost, the time server reports a 61st second at the end of the day (with a value of 60); if gained, the seconds of UTC go 56, 57, 58, 00, 01.