Mixing
Unix time and leap seconds
Regarding Unix (POSIX) time, Wikipedia says:
Due to its handling of leap seconds, it is neither a linear representation of time nor a true representation of UTC.
But the Unix date command does not seem to be aware of them actually
$ date -d '@867715199' --utc
Mon Jun 30 23:59:59 UTC 1997
$ date -d '@867715200' --utc
Tue Jul 1 00:00:00 UTC 1997
While there should be a leap second there at Mon Jun 30 23:59:60 UTC 1997.
Does this mean that only the date command ignores leap seconds, while the concept of Unix time doesn't?
shell unix-timestamp leap-second
asked May 14 '13 at 9:22
CampaCampa
2,04732229
add a comment |
Regarding Unix (POSIX) time, Wikipedia says:
Due to its handling of leap seconds, it is neither a linear representation of time nor a true representation of UTC.
But the Unix date command does not seem to be aware of them actually
$ date -d '@867715199' --utc
Mon Jun 30 23:59:59 UTC 1997
$ date -d '@867715200' --utc
Tue Jul 1 00:00:00 UTC 1997
While there should be a leap second there at Mon Jun 30 23:59:60 UTC 1997.
Does this mean that only the date command ignores leap seconds, while the concept of Unix time doesn't?
shell unix-timestamp leap-second
asked May 14 '13 at 9:22
CampaCampa
2,04732229
7
There's a nice recap of utc/tai at madore.org/~david/computers/unix-leap-seconds.html
– loreb
May 15 '13 at 14:23
1
This page explains how OSes deal/should deal with leap second information from ntp, meinbergglobal.com/english/info/leap-second.htm#os
– Silver Moon
Jan 28 '17 at 12:53
add a comment |
Regarding Unix (POSIX) time, Wikipedia says:
Due to its handling of leap seconds, it is neither a linear representation of time nor a true representation of UTC.
But the Unix date command does not seem to be aware of them actually
$ date -d '@867715199' --utc
Mon Jun 30 23:59:59 UTC 1997
$ date -d '@867715200' --utc
Tue Jul 1 00:00:00 UTC 1997
While there should be a leap second there at Mon Jun 30 23:59:60 UTC 1997.
Does this mean that only the date command ignores leap seconds, while the concept of Unix time doesn't?
shell unix-timestamp leap-second
asked May 14 '13 at 9:22
CampaCampa
2,04732229
Regarding Unix (POSIX) time, Wikipedia says:
Due to its handling of leap seconds, it is neither a linear representation of time nor a true representation of UTC.
But the Unix date command does not seem to be aware of them actually
$ date -d '@867715199' --utc
Mon Jun 30 23:59:59 UTC 1997
$ date -d '@867715200' --utc
Tue Jul 1 00:00:00 UTC 1997
While there should be a leap second there at Mon Jun 30 23:59:60 UTC 1997.
Does this mean that only the date command ignores leap seconds, while the concept of Unix time doesn't?
shell unix-timestamp leap-second
shell unix-timestamp leap-second
asked May 14 '13 at 9:22
CampaCampa
2,04732229
asked May 14 '13 at 9:22
CampaCampa
2,04732229
asked May 14 '13 at 9:22
CampaCampa
2,04732229
asked May 14 '13 at 9:22
CampaCampa
2,04732229
asked May 14 '13 at 9:22
CampaCampa
2,04732229
2,04732229
7
There's a nice recap of utc/tai at madore.org/~david/computers/unix-leap-seconds.html
– loreb
May 15 '13 at 14:23
1
This page explains how OSes deal/should deal with leap second information from ntp, meinbergglobal.com/english/info/leap-second.htm#os
– Silver Moon
Jan 28 '17 at 12:53
add a comment |
7
There's a nice recap of utc/tai at madore.org/~david/computers/unix-leap-seconds.html
– loreb
May 15 '13 at 14:23
1
This page explains how OSes deal/should deal with leap second information from ntp, meinbergglobal.com/english/info/leap-second.htm#os
– Silver Moon
Jan 28 '17 at 12:53
7
7
There's a nice recap of utc/tai at madore.org/~david/computers/unix-leap-seconds.html
– loreb
May 15 '13 at 14:23
There's a nice recap of utc/tai at madore.org/~david/computers/unix-leap-seconds.html
– loreb
May 15 '13 at 14:23
1
1
This page explains how OSes deal/should deal with leap second information from ntp, meinbergglobal.com/english/info/leap-second.htm#os
– Silver Moon
Jan 28 '17 at 12:53
This page explains how OSes deal/should deal with leap second information from ntp, meinbergglobal.com/english/info/leap-second.htm#os
– Silver Moon
Jan 28 '17 at 12:53
add a comment |
3 Answers
3
active
oldest
votes
The number of seconds per day are fixed with Unix timestamps.
The Unix time number is zero at the Unix epoch, and increases by
exactly 86400 per day since the epoch.
So it cannot represent leap seconds. The OS will slow down the clock to accommodate for this. The leap seconds is simply not existent as far a Unix timestamps are concerned.
edited Oct 25 '16 at 17:06
Nat
3,0581420
answered May 14 '13 at 9:24
Thomas JungThomas Jung
26.3k871107
1
A unix second is allowed to be different from a "real" second. The unix day has 86400s which are actually 86401 real seconds (for days with leap seconds). Otherwise the clock is ahead like TAI: TAI has been exactly 35 seconds ahead of UTC. The 35 seconds results from the initial difference of 10 seconds at the start of 1972, plus 25 leap seconds in UTC since 1972.
– Thomas Jung
May 15 '13 at 8:05
3
@ThomasJung, Your answer is misleading / wrong. 1) The Unix time can and does represent leap seconds, albeit not unambiguously. For example, UTC 1998-12-31 23:59:60.25 is represented as Unix time 915148800.25. If the number of seconds were fixed with Unix timestamps, we would have 86400 unique integer Unix timestamps per day, every day. Although Unix timestamps increase by 86400 per day, it doesn't mean that we have 86400 seconds in Unix timestamps per day. Not every real number is a valid Unix timestamp due to negative leap seconds, and not every real..
– Pacerier
Jun 16 '13 at 17:31
1
..number is a unique Unix timestamp due to positive leap seconds. 2) Leap seconds do exist as far as Unix timestamps are concerned. If they didn't, Unix time will freeze during a leap second, which it doesn't.
– Pacerier
Jun 16 '13 at 19:37
1
@Campa: TAI time continues to tick during a leap seconds as always (each intercalary leap second increases TAI - UTC difference. POSIX time is UTC time (excluding moments during leap seconds). TAI can tell actual elapsed UTC (SI) seconds, POSIX -- UT (Earth rotation) seconds (because UTC is within 0.9 seconds from UT). To find the actual number of elapsed seconds between two events given in UTC, you need to know the corresponding leap counts at each event e.g., 2010-01-01 -- 34 leap seconds, 2013-01-01 -- 35 leap seconds.
– jfs
Sep 15 '14 at 0:22
2
@Jung : could you please rephrase to "So it cannot represent leap seconds unambiguously " ?
– Campa
Apr 23 '15 at 7:25
|
show 12 more comments
Unix time is easy to work with, but some timestamps are not real times, and some timestamps are not unique times.
That is, there are some duplicate timestamps representing two different seconds in time, because in unix time the sixtieth second might have to repeat itself (as there can't be a sixty-first second). Theoretically, they could also be gaps in the future because the sixtieth second doesn't have to exist, although no skipping leap seconds have been issued so far.
Rationale for unix time: it's defined so that it's easy to work with. Adding support for leap seconds to the standard libraries is very tricky. For example, you want to represent 1 Jan 2050 in a database. No-one on earth knows how many seconds away that date is in UTC! The date can't be stored as a UTC timestamp, because the IAU doesn't know how many leap seconds we'll have to add in the next decades (they're as good as random). So how can a programmer do date arithmetic when the length of time which will elapse between any two dates in the future isn't know until a year or two before? Unix time is simple: we know the timestamp of 1 Jan 2050 already (namely, 80 years * #of seconds in a year). UTC is extremely hard to work with all year round, whereas unix time is only hard to work with in the instant a leap second occurs.
For what it's worth, I've never met a programmer who agrees with leap seconds. They should clearly be abolished.
answered May 14 '13 at 9:36
Nicholas WilsonNicholas Wilson
7,14212468
1
No, unix time never has leap seconds. It's synced with UTC, that is, unix time ticks at the same moment as UTC ticks: the second has exactly the same length, and they line up. Sometimes when unix time ticks though its value goes up by two, whereas UTC only ever goes up by one. Unix time is massively, massively easier than any system with leap seconds because leap seconds are a total joke.
– Nicholas Wilson
May 14 '13 at 13:29
1
Sorry, stupid mistake in last comment. Third sentence should read: "Sometimes when unix time ticks though its value repeats the previous second, whereas UTC only ever goes up by one."
– Nicholas Wilson
May 14 '13 at 13:40
3
@Pacerier OK, so 1 Jan 2050, 00:00:00 is 2524629600. What's the UTC timestamp for that? No-one knows. That's a big issue for programmers: either you write a lot of code, or do some really sloppy programming (which might not even be legal, depending on any regulation the software has to comply with). Leap seconds are as good as random, in that we don't know when they'll come. We don't have any models that accurately predict the earth's wobble, we just have to wait and see each year. Of course it's deterministic, but that's no help either to programmers or the IAU.
– Nicholas Wilson
Jun 17 '13 at 9:51
1
You seem to be stuck to the idea that a timestamp must be a reflection of a count of seconds, though in fact goo.gl/QWsOo a timestamp is simply a sequence of characters or encoded information. In other words, the string "1 Jan 2050, 00:00:00" is in fact a UTC timestamp by itself if we can decode it to the UTC time "1 Jan 2050, 00:00:00". If you don't like alphanumerics, we can always convert this to any arbitrary encoded integer like "2498729866093" and it's still a UTC timestamp as long as the receiver........
– Pacerier
Jun 21 '13 at 2:21
2
I've deleted my comments. You win. If you want to learn, start by learning about probability distributions.
– jfs
Oct 30 '14 at 9:19
|
show 15 more comments
Since both of the other answers contain lots of misleading information, I'll throw this in.
Thomas is right that the number of Unix Epoch timestamp seconds per day are fixed. What this means is that on days where there is a leap second, the second right before midnight (the 61st second of the UTC minute before midnight) is given the same timestamp as the previous second.
That timestamp is "replayed", if you will. So the same unix timestamp will be used for two real-world seconds. This also means that if you're getting fraction unix epochs, the whole second will repeat.
X86399.0, X86399.5, X86400.0, X86400.5, X86400.0, X86400.5, then X86401.0.
So unix time can't unambiguously represent leap seconds - the leap second timestamp is also the timestamp for the previous real-world second.
answered Jan 1 at 22:37
B TB T
28.3k25136166
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f16539436%2funix-time-and-leap-seconds%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
The number of seconds per day are fixed with Unix timestamps.
The Unix time number is zero at the Unix epoch, and increases by
exactly 86400 per day since the epoch.
So it cannot represent leap seconds. The OS will slow down the clock to accommodate for this. The leap seconds is simply not existent as far a Unix timestamps are concerned.
edited Oct 25 '16 at 17:06
Nat
3,0581420
answered May 14 '13 at 9:24
Thomas JungThomas Jung
26.3k871107
1
A unix second is allowed to be different from a "real" second. The unix day has 86400s which are actually 86401 real seconds (for days with leap seconds). Otherwise the clock is ahead like TAI: TAI has been exactly 35 seconds ahead of UTC. The 35 seconds results from the initial difference of 10 seconds at the start of 1972, plus 25 leap seconds in UTC since 1972.
– Thomas Jung
May 15 '13 at 8:05
3
@ThomasJung, Your answer is misleading / wrong. 1) The Unix time can and does represent leap seconds, albeit not unambiguously. For example, UTC 1998-12-31 23:59:60.25 is represented as Unix time 915148800.25. If the number of seconds were fixed with Unix timestamps, we would have 86400 unique integer Unix timestamps per day, every day. Although Unix timestamps increase by 86400 per day, it doesn't mean that we have 86400 seconds in Unix timestamps per day. Not every real number is a valid Unix timestamp due to negative leap seconds, and not every real..
– Pacerier
Jun 16 '13 at 17:31
1
..number is a unique Unix timestamp due to positive leap seconds. 2) Leap seconds do exist as far as Unix timestamps are concerned. If they didn't, Unix time will freeze during a leap second, which it doesn't.
– Pacerier
Jun 16 '13 at 19:37
1
@Campa: TAI time continues to tick during a leap seconds as always (each intercalary leap second increases TAI - UTC difference. POSIX time is UTC time (excluding moments during leap seconds). TAI can tell actual elapsed UTC (SI) seconds, POSIX -- UT (Earth rotation) seconds (because UTC is within 0.9 seconds from UT). To find the actual number of elapsed seconds between two events given in UTC, you need to know the corresponding leap counts at each event e.g., 2010-01-01 -- 34 leap seconds, 2013-01-01 -- 35 leap seconds.
– jfs
Sep 15 '14 at 0:22
2
@Jung : could you please rephrase to "So it cannot represent leap seconds unambiguously " ?
– Campa
Apr 23 '15 at 7:25
|
show 12 more comments
The number of seconds per day are fixed with Unix timestamps.
The Unix time number is zero at the Unix epoch, and increases by
exactly 86400 per day since the epoch.
So it cannot represent leap seconds. The OS will slow down the clock to accommodate for this. The leap seconds is simply not existent as far a Unix timestamps are concerned.
edited Oct 25 '16 at 17:06
Nat
3,0581420
answered May 14 '13 at 9:24
Thomas JungThomas Jung
26.3k871107
1
A unix second is allowed to be different from a "real" second. The unix day has 86400s which are actually 86401 real seconds (for days with leap seconds). Otherwise the clock is ahead like TAI: TAI has been exactly 35 seconds ahead of UTC. The 35 seconds results from the initial difference of 10 seconds at the start of 1972, plus 25 leap seconds in UTC since 1972.
– Thomas Jung
May 15 '13 at 8:05
3
@ThomasJung, Your answer is misleading / wrong. 1) The Unix time can and does represent leap seconds, albeit not unambiguously. For example, UTC 1998-12-31 23:59:60.25 is represented as Unix time 915148800.25. If the number of seconds were fixed with Unix timestamps, we would have 86400 unique integer Unix timestamps per day, every day. Although Unix timestamps increase by 86400 per day, it doesn't mean that we have 86400 seconds in Unix timestamps per day. Not every real number is a valid Unix timestamp due to negative leap seconds, and not every real..
– Pacerier
Jun 16 '13 at 17:31
1
..number is a unique Unix timestamp due to positive leap seconds. 2) Leap seconds do exist as far as Unix timestamps are concerned. If they didn't, Unix time will freeze during a leap second, which it doesn't.
– Pacerier
Jun 16 '13 at 19:37
1
@Campa: TAI time continues to tick during a leap seconds as always (each intercalary leap second increases TAI - UTC difference. POSIX time is UTC time (excluding moments during leap seconds). TAI can tell actual elapsed UTC (SI) seconds, POSIX -- UT (Earth rotation) seconds (because UTC is within 0.9 seconds from UT). To find the actual number of elapsed seconds between two events given in UTC, you need to know the corresponding leap counts at each event e.g., 2010-01-01 -- 34 leap seconds, 2013-01-01 -- 35 leap seconds.
– jfs
Sep 15 '14 at 0:22
2
@Jung : could you please rephrase to "So it cannot represent leap seconds unambiguously " ?
– Campa
Apr 23 '15 at 7:25
|
show 12 more comments
The number of seconds per day are fixed with Unix timestamps.
The Unix time number is zero at the Unix epoch, and increases by
exactly 86400 per day since the epoch.
So it cannot represent leap seconds. The OS will slow down the clock to accommodate for this. The leap seconds is simply not existent as far a Unix timestamps are concerned.
edited Oct 25 '16 at 17:06
Nat
3,0581420
answered May 14 '13 at 9:24
Thomas JungThomas Jung
26.3k871107
The number of seconds per day are fixed with Unix timestamps.
The Unix time number is zero at the Unix epoch, and increases by
exactly 86400 per day since the epoch.
So it cannot represent leap seconds. The OS will slow down the clock to accommodate for this. The leap seconds is simply not existent as far a Unix timestamps are concerned.
edited Oct 25 '16 at 17:06
Nat
3,0581420
answered May 14 '13 at 9:24
Thomas JungThomas Jung
26.3k871107
edited Oct 25 '16 at 17:06
Nat
3,0581420
edited Oct 25 '16 at 17:06
Nat
3,0581420
edited Oct 25 '16 at 17:06
Nat
3,0581420
3,0581420
answered May 14 '13 at 9:24
Thomas JungThomas Jung
26.3k871107
answered May 14 '13 at 9:24
Thomas JungThomas Jung
26.3k871107
answered May 14 '13 at 9:24
Thomas JungThomas Jung
26.3k871107
26.3k871107
1
A unix second is allowed to be different from a "real" second. The unix day has 86400s which are actually 86401 real seconds (for days with leap seconds). Otherwise the clock is ahead like TAI: TAI has been exactly 35 seconds ahead of UTC. The 35 seconds results from the initial difference of 10 seconds at the start of 1972, plus 25 leap seconds in UTC since 1972.
– Thomas Jung
May 15 '13 at 8:05
3
@ThomasJung, Your answer is misleading / wrong. 1) The Unix time can and does represent leap seconds, albeit not unambiguously. For example, UTC 1998-12-31 23:59:60.25 is represented as Unix time 915148800.25. If the number of seconds were fixed with Unix timestamps, we would have 86400 unique integer Unix timestamps per day, every day. Although Unix timestamps increase by 86400 per day, it doesn't mean that we have 86400 seconds in Unix timestamps per day. Not every real number is a valid Unix timestamp due to negative leap seconds, and not every real..
– Pacerier
Jun 16 '13 at 17:31
1
..number is a unique Unix timestamp due to positive leap seconds. 2) Leap seconds do exist as far as Unix timestamps are concerned. If they didn't, Unix time will freeze during a leap second, which it doesn't.
– Pacerier
Jun 16 '13 at 19:37
1
@Campa: TAI time continues to tick during a leap seconds as always (each intercalary leap second increases TAI - UTC difference. POSIX time is UTC time (excluding moments during leap seconds). TAI can tell actual elapsed UTC (SI) seconds, POSIX -- UT (Earth rotation) seconds (because UTC is within 0.9 seconds from UT). To find the actual number of elapsed seconds between two events given in UTC, you need to know the corresponding leap counts at each event e.g., 2010-01-01 -- 34 leap seconds, 2013-01-01 -- 35 leap seconds.
– jfs
Sep 15 '14 at 0:22
2
@Jung : could you please rephrase to "So it cannot represent leap seconds unambiguously " ?
– Campa
Apr 23 '15 at 7:25
|
show 12 more comments
1
A unix second is allowed to be different from a "real" second. The unix day has 86400s which are actually 86401 real seconds (for days with leap seconds). Otherwise the clock is ahead like TAI: TAI has been exactly 35 seconds ahead of UTC. The 35 seconds results from the initial difference of 10 seconds at the start of 1972, plus 25 leap seconds in UTC since 1972.
– Thomas Jung
May 15 '13 at 8:05
3
@ThomasJung, Your answer is misleading / wrong. 1) The Unix time can and does represent leap seconds, albeit not unambiguously. For example, UTC 1998-12-31 23:59:60.25 is represented as Unix time 915148800.25. If the number of seconds were fixed with Unix timestamps, we would have 86400 unique integer Unix timestamps per day, every day. Although Unix timestamps increase by 86400 per day, it doesn't mean that we have 86400 seconds in Unix timestamps per day. Not every real number is a valid Unix timestamp due to negative leap seconds, and not every real..
– Pacerier
Jun 16 '13 at 17:31
1
..number is a unique Unix timestamp due to positive leap seconds. 2) Leap seconds do exist as far as Unix timestamps are concerned. If they didn't, Unix time will freeze during a leap second, which it doesn't.
– Pacerier
Jun 16 '13 at 19:37
1
@Campa: TAI time continues to tick during a leap seconds as always (each intercalary leap second increases TAI - UTC difference. POSIX time is UTC time (excluding moments during leap seconds). TAI can tell actual elapsed UTC (SI) seconds, POSIX -- UT (Earth rotation) seconds (because UTC is within 0.9 seconds from UT). To find the actual number of elapsed seconds between two events given in UTC, you need to know the corresponding leap counts at each event e.g., 2010-01-01 -- 34 leap seconds, 2013-01-01 -- 35 leap seconds.
– jfs
Sep 15 '14 at 0:22
2
@Jung : could you please rephrase to "So it cannot represent leap seconds unambiguously " ?
– Campa
Apr 23 '15 at 7:25
1
1
A unix second is allowed to be different from a "real" second. The unix day has 86400s which are actually 86401 real seconds (for days with leap seconds). Otherwise the clock is ahead like TAI: TAI has been exactly 35 seconds ahead of UTC. The 35 seconds results from the initial difference of 10 seconds at the start of 1972, plus 25 leap seconds in UTC since 1972.
– Thomas Jung
May 15 '13 at 8:05
A unix second is allowed to be different from a "real" second. The unix day has 86400s which are actually 86401 real seconds (for days with leap seconds). Otherwise the clock is ahead like TAI: TAI has been exactly 35 seconds ahead of UTC. The 35 seconds results from the initial difference of 10 seconds at the start of 1972, plus 25 leap seconds in UTC since 1972.
– Thomas Jung
May 15 '13 at 8:05
3
3
@ThomasJung, Your answer is misleading / wrong. 1) The Unix time can and does represent leap seconds, albeit not unambiguously. For example, UTC 1998-12-31 23:59:60.25 is represented as Unix time 915148800.25. If the number of seconds were fixed with Unix timestamps, we would have 86400 unique integer Unix timestamps per day, every day. Although Unix timestamps increase by 86400 per day, it doesn't mean that we have 86400 seconds in Unix timestamps per day. Not every real number is a valid Unix timestamp due to negative leap seconds, and not every real..
– Pacerier
Jun 16 '13 at 17:31
@ThomasJung, Your answer is misleading / wrong. 1) The Unix time can and does represent leap seconds, albeit not unambiguously. For example, UTC 1998-12-31 23:59:60.25 is represented as Unix time 915148800.25. If the number of seconds were fixed with Unix timestamps, we would have 86400 unique integer Unix timestamps per day, every day. Although Unix timestamps increase by 86400 per day, it doesn't mean that we have 86400 seconds in Unix timestamps per day. Not every real number is a valid Unix timestamp due to negative leap seconds, and not every real..
– Pacerier
Jun 16 '13 at 17:31
1
1
..number is a unique Unix timestamp due to positive leap seconds. 2) Leap seconds do exist as far as Unix timestamps are concerned. If they didn't, Unix time will freeze during a leap second, which it doesn't.
– Pacerier
Jun 16 '13 at 19:37
..number is a unique Unix timestamp due to positive leap seconds. 2) Leap seconds do exist as far as Unix timestamps are concerned. If they didn't, Unix time will freeze during a leap second, which it doesn't.
– Pacerier
Jun 16 '13 at 19:37
1
1
@Campa: TAI time continues to tick during a leap seconds as always (each intercalary leap second increases TAI - UTC difference. POSIX time is UTC time (excluding moments during leap seconds). TAI can tell actual elapsed UTC (SI) seconds, POSIX -- UT (Earth rotation) seconds (because UTC is within 0.9 seconds from UT). To find the actual number of elapsed seconds between two events given in UTC, you need to know the corresponding leap counts at each event e.g., 2010-01-01 -- 34 leap seconds, 2013-01-01 -- 35 leap seconds.
– jfs
Sep 15 '14 at 0:22
@Campa: TAI time continues to tick during a leap seconds as always (each intercalary leap second increases TAI - UTC difference. POSIX time is UTC time (excluding moments during leap seconds). TAI can tell actual elapsed UTC (SI) seconds, POSIX -- UT (Earth rotation) seconds (because UTC is within 0.9 seconds from UT). To find the actual number of elapsed seconds between two events given in UTC, you need to know the corresponding leap counts at each event e.g., 2010-01-01 -- 34 leap seconds, 2013-01-01 -- 35 leap seconds.
– jfs
Sep 15 '14 at 0:22
2
2
@Jung : could you please rephrase to "So it cannot represent leap seconds unambiguously " ?
– Campa
Apr 23 '15 at 7:25
@Jung : could you please rephrase to "So it cannot represent leap seconds unambiguously " ?
– Campa
Apr 23 '15 at 7:25
|
show 12 more comments
Unix time is easy to work with, but some timestamps are not real times, and some timestamps are not unique times.
That is, there are some duplicate timestamps representing two different seconds in time, because in unix time the sixtieth second might have to repeat itself (as there can't be a sixty-first second). Theoretically, they could also be gaps in the future because the sixtieth second doesn't have to exist, although no skipping leap seconds have been issued so far.
Rationale for unix time: it's defined so that it's easy to work with. Adding support for leap seconds to the standard libraries is very tricky. For example, you want to represent 1 Jan 2050 in a database. No-one on earth knows how many seconds away that date is in UTC! The date can't be stored as a UTC timestamp, because the IAU doesn't know how many leap seconds we'll have to add in the next decades (they're as good as random). So how can a programmer do date arithmetic when the length of time which will elapse between any two dates in the future isn't know until a year or two before? Unix time is simple: we know the timestamp of 1 Jan 2050 already (namely, 80 years * #of seconds in a year). UTC is extremely hard to work with all year round, whereas unix time is only hard to work with in the instant a leap second occurs.
For what it's worth, I've never met a programmer who agrees with leap seconds. They should clearly be abolished.
answered May 14 '13 at 9:36
Nicholas WilsonNicholas Wilson
7,14212468
1
No, unix time never has leap seconds. It's synced with UTC, that is, unix time ticks at the same moment as UTC ticks: the second has exactly the same length, and they line up. Sometimes when unix time ticks though its value goes up by two, whereas UTC only ever goes up by one. Unix time is massively, massively easier than any system with leap seconds because leap seconds are a total joke.
– Nicholas Wilson
May 14 '13 at 13:29
1
Sorry, stupid mistake in last comment. Third sentence should read: "Sometimes when unix time ticks though its value repeats the previous second, whereas UTC only ever goes up by one."
– Nicholas Wilson
May 14 '13 at 13:40
3
@Pacerier OK, so 1 Jan 2050, 00:00:00 is 2524629600. What's the UTC timestamp for that? No-one knows. That's a big issue for programmers: either you write a lot of code, or do some really sloppy programming (which might not even be legal, depending on any regulation the software has to comply with). Leap seconds are as good as random, in that we don't know when they'll come. We don't have any models that accurately predict the earth's wobble, we just have to wait and see each year. Of course it's deterministic, but that's no help either to programmers or the IAU.
– Nicholas Wilson
Jun 17 '13 at 9:51
1
You seem to be stuck to the idea that a timestamp must be a reflection of a count of seconds, though in fact goo.gl/QWsOo a timestamp is simply a sequence of characters or encoded information. In other words, the string "1 Jan 2050, 00:00:00" is in fact a UTC timestamp by itself if we can decode it to the UTC time "1 Jan 2050, 00:00:00". If you don't like alphanumerics, we can always convert this to any arbitrary encoded integer like "2498729866093" and it's still a UTC timestamp as long as the receiver........
– Pacerier
Jun 21 '13 at 2:21
2
I've deleted my comments. You win. If you want to learn, start by learning about probability distributions.
– jfs
Oct 30 '14 at 9:19
|
show 15 more comments
Unix time is easy to work with, but some timestamps are not real times, and some timestamps are not unique times.
That is, there are some duplicate timestamps representing two different seconds in time, because in unix time the sixtieth second might have to repeat itself (as there can't be a sixty-first second). Theoretically, they could also be gaps in the future because the sixtieth second doesn't have to exist, although no skipping leap seconds have been issued so far.
Rationale for unix time: it's defined so that it's easy to work with. Adding support for leap seconds to the standard libraries is very tricky. For example, you want to represent 1 Jan 2050 in a database. No-one on earth knows how many seconds away that date is in UTC! The date can't be stored as a UTC timestamp, because the IAU doesn't know how many leap seconds we'll have to add in the next decades (they're as good as random). So how can a programmer do date arithmetic when the length of time which will elapse between any two dates in the future isn't know until a year or two before? Unix time is simple: we know the timestamp of 1 Jan 2050 already (namely, 80 years * #of seconds in a year). UTC is extremely hard to work with all year round, whereas unix time is only hard to work with in the instant a leap second occurs.
For what it's worth, I've never met a programmer who agrees with leap seconds. They should clearly be abolished.
answered May 14 '13 at 9:36
Nicholas WilsonNicholas Wilson
7,14212468
1
No, unix time never has leap seconds. It's synced with UTC, that is, unix time ticks at the same moment as UTC ticks: the second has exactly the same length, and they line up. Sometimes when unix time ticks though its value goes up by two, whereas UTC only ever goes up by one. Unix time is massively, massively easier than any system with leap seconds because leap seconds are a total joke.
– Nicholas Wilson
May 14 '13 at 13:29
1
Sorry, stupid mistake in last comment. Third sentence should read: "Sometimes when unix time ticks though its value repeats the previous second, whereas UTC only ever goes up by one."
– Nicholas Wilson
May 14 '13 at 13:40
3
@Pacerier OK, so 1 Jan 2050, 00:00:00 is 2524629600. What's the UTC timestamp for that? No-one knows. That's a big issue for programmers: either you write a lot of code, or do some really sloppy programming (which might not even be legal, depending on any regulation the software has to comply with). Leap seconds are as good as random, in that we don't know when they'll come. We don't have any models that accurately predict the earth's wobble, we just have to wait and see each year. Of course it's deterministic, but that's no help either to programmers or the IAU.
– Nicholas Wilson
Jun 17 '13 at 9:51
1
You seem to be stuck to the idea that a timestamp must be a reflection of a count of seconds, though in fact goo.gl/QWsOo a timestamp is simply a sequence of characters or encoded information. In other words, the string "1 Jan 2050, 00:00:00" is in fact a UTC timestamp by itself if we can decode it to the UTC time "1 Jan 2050, 00:00:00". If you don't like alphanumerics, we can always convert this to any arbitrary encoded integer like "2498729866093" and it's still a UTC timestamp as long as the receiver........
– Pacerier
Jun 21 '13 at 2:21
2
I've deleted my comments. You win. If you want to learn, start by learning about probability distributions.
– jfs
Oct 30 '14 at 9:19
|
show 15 more comments
Unix time is easy to work with, but some timestamps are not real times, and some timestamps are not unique times.
That is, there are some duplicate timestamps representing two different seconds in time, because in unix time the sixtieth second might have to repeat itself (as there can't be a sixty-first second). Theoretically, they could also be gaps in the future because the sixtieth second doesn't have to exist, although no skipping leap seconds have been issued so far.
Rationale for unix time: it's defined so that it's easy to work with. Adding support for leap seconds to the standard libraries is very tricky. For example, you want to represent 1 Jan 2050 in a database. No-one on earth knows how many seconds away that date is in UTC! The date can't be stored as a UTC timestamp, because the IAU doesn't know how many leap seconds we'll have to add in the next decades (they're as good as random). So how can a programmer do date arithmetic when the length of time which will elapse between any two dates in the future isn't know until a year or two before? Unix time is simple: we know the timestamp of 1 Jan 2050 already (namely, 80 years * #of seconds in a year). UTC is extremely hard to work with all year round, whereas unix time is only hard to work with in the instant a leap second occurs.
For what it's worth, I've never met a programmer who agrees with leap seconds. They should clearly be abolished.
answered May 14 '13 at 9:36
Nicholas WilsonNicholas Wilson
7,14212468
Unix time is easy to work with, but some timestamps are not real times, and some timestamps are not unique times.
That is, there are some duplicate timestamps representing two different seconds in time, because in unix time the sixtieth second might have to repeat itself (as there can't be a sixty-first second). Theoretically, they could also be gaps in the future because the sixtieth second doesn't have to exist, although no skipping leap seconds have been issued so far.
Rationale for unix time: it's defined so that it's easy to work with. Adding support for leap seconds to the standard libraries is very tricky. For example, you want to represent 1 Jan 2050 in a database. No-one on earth knows how many seconds away that date is in UTC! The date can't be stored as a UTC timestamp, because the IAU doesn't know how many leap seconds we'll have to add in the next decades (they're as good as random). So how can a programmer do date arithmetic when the length of time which will elapse between any two dates in the future isn't know until a year or two before? Unix time is simple: we know the timestamp of 1 Jan 2050 already (namely, 80 years * #of seconds in a year). UTC is extremely hard to work with all year round, whereas unix time is only hard to work with in the instant a leap second occurs.
For what it's worth, I've never met a programmer who agrees with leap seconds. They should clearly be abolished.
answered May 14 '13 at 9:36
Nicholas WilsonNicholas Wilson
7,14212468
edited May 14 '13 at 13:36
answered May 14 '13 at 9:36
Nicholas WilsonNicholas Wilson
7,14212468
answered May 14 '13 at 9:36
Nicholas WilsonNicholas Wilson
7,14212468
answered May 14 '13 at 9:36
Nicholas WilsonNicholas Wilson
7,14212468
7,14212468
1
No, unix time never has leap seconds. It's synced with UTC, that is, unix time ticks at the same moment as UTC ticks: the second has exactly the same length, and they line up. Sometimes when unix time ticks though its value goes up by two, whereas UTC only ever goes up by one. Unix time is massively, massively easier than any system with leap seconds because leap seconds are a total joke.
– Nicholas Wilson
May 14 '13 at 13:29
1
Sorry, stupid mistake in last comment. Third sentence should read: "Sometimes when unix time ticks though its value repeats the previous second, whereas UTC only ever goes up by one."
– Nicholas Wilson
May 14 '13 at 13:40
3
@Pacerier OK, so 1 Jan 2050, 00:00:00 is 2524629600. What's the UTC timestamp for that? No-one knows. That's a big issue for programmers: either you write a lot of code, or do some really sloppy programming (which might not even be legal, depending on any regulation the software has to comply with). Leap seconds are as good as random, in that we don't know when they'll come. We don't have any models that accurately predict the earth's wobble, we just have to wait and see each year. Of course it's deterministic, but that's no help either to programmers or the IAU.
– Nicholas Wilson
Jun 17 '13 at 9:51
1
You seem to be stuck to the idea that a timestamp must be a reflection of a count of seconds, though in fact goo.gl/QWsOo a timestamp is simply a sequence of characters or encoded information. In other words, the string "1 Jan 2050, 00:00:00" is in fact a UTC timestamp by itself if we can decode it to the UTC time "1 Jan 2050, 00:00:00". If you don't like alphanumerics, we can always convert this to any arbitrary encoded integer like "2498729866093" and it's still a UTC timestamp as long as the receiver........
– Pacerier
Jun 21 '13 at 2:21
2
I've deleted my comments. You win. If you want to learn, start by learning about probability distributions.
– jfs
Oct 30 '14 at 9:19
|
show 15 more comments
1
No, unix time never has leap seconds. It's synced with UTC, that is, unix time ticks at the same moment as UTC ticks: the second has exactly the same length, and they line up. Sometimes when unix time ticks though its value goes up by two, whereas UTC only ever goes up by one. Unix time is massively, massively easier than any system with leap seconds because leap seconds are a total joke.
– Nicholas Wilson
May 14 '13 at 13:29
1
Sorry, stupid mistake in last comment. Third sentence should read: "Sometimes when unix time ticks though its value repeats the previous second, whereas UTC only ever goes up by one."
– Nicholas Wilson
May 14 '13 at 13:40
3
@Pacerier OK, so 1 Jan 2050, 00:00:00 is 2524629600. What's the UTC timestamp for that? No-one knows. That's a big issue for programmers: either you write a lot of code, or do some really sloppy programming (which might not even be legal, depending on any regulation the software has to comply with). Leap seconds are as good as random, in that we don't know when they'll come. We don't have any models that accurately predict the earth's wobble, we just have to wait and see each year. Of course it's deterministic, but that's no help either to programmers or the IAU.
– Nicholas Wilson
Jun 17 '13 at 9:51
1
You seem to be stuck to the idea that a timestamp must be a reflection of a count of seconds, though in fact goo.gl/QWsOo a timestamp is simply a sequence of characters or encoded information. In other words, the string "1 Jan 2050, 00:00:00" is in fact a UTC timestamp by itself if we can decode it to the UTC time "1 Jan 2050, 00:00:00". If you don't like alphanumerics, we can always convert this to any arbitrary encoded integer like "2498729866093" and it's still a UTC timestamp as long as the receiver........
– Pacerier
Jun 21 '13 at 2:21
2
I've deleted my comments. You win. If you want to learn, start by learning about probability distributions.
– jfs
Oct 30 '14 at 9:19
1
1
No, unix time never has leap seconds. It's synced with UTC, that is, unix time ticks at the same moment as UTC ticks: the second has exactly the same length, and they line up. Sometimes when unix time ticks though its value goes up by two, whereas UTC only ever goes up by one. Unix time is massively, massively easier than any system with leap seconds because leap seconds are a total joke.
– Nicholas Wilson
May 14 '13 at 13:29
No, unix time never has leap seconds. It's synced with UTC, that is, unix time ticks at the same moment as UTC ticks: the second has exactly the same length, and they line up. Sometimes when unix time ticks though its value goes up by two, whereas UTC only ever goes up by one. Unix time is massively, massively easier than any system with leap seconds because leap seconds are a total joke.
– Nicholas Wilson
May 14 '13 at 13:29
1
1
Sorry, stupid mistake in last comment. Third sentence should read: "Sometimes when unix time ticks though its value repeats the previous second, whereas UTC only ever goes up by one."
– Nicholas Wilson
May 14 '13 at 13:40
Sorry, stupid mistake in last comment. Third sentence should read: "Sometimes when unix time ticks though its value repeats the previous second, whereas UTC only ever goes up by one."
– Nicholas Wilson
May 14 '13 at 13:40
3
3
@Pacerier OK, so 1 Jan 2050, 00:00:00 is 2524629600. What's the UTC timestamp for that? No-one knows. That's a big issue for programmers: either you write a lot of code, or do some really sloppy programming (which might not even be legal, depending on any regulation the software has to comply with). Leap seconds are as good as random, in that we don't know when they'll come. We don't have any models that accurately predict the earth's wobble, we just have to wait and see each year. Of course it's deterministic, but that's no help either to programmers or the IAU.
– Nicholas Wilson
Jun 17 '13 at 9:51
@Pacerier OK, so 1 Jan 2050, 00:00:00 is 2524629600. What's the UTC timestamp for that? No-one knows. That's a big issue for programmers: either you write a lot of code, or do some really sloppy programming (which might not even be legal, depending on any regulation the software has to comply with). Leap seconds are as good as random, in that we don't know when they'll come. We don't have any models that accurately predict the earth's wobble, we just have to wait and see each year. Of course it's deterministic, but that's no help either to programmers or the IAU.
– Nicholas Wilson
Jun 17 '13 at 9:51
1
1
You seem to be stuck to the idea that a timestamp must be a reflection of a count of seconds, though in fact goo.gl/QWsOo a timestamp is simply a sequence of characters or encoded information. In other words, the string "1 Jan 2050, 00:00:00" is in fact a UTC timestamp by itself if we can decode it to the UTC time "1 Jan 2050, 00:00:00". If you don't like alphanumerics, we can always convert this to any arbitrary encoded integer like "2498729866093" and it's still a UTC timestamp as long as the receiver........
– Pacerier
Jun 21 '13 at 2:21
You seem to be stuck to the idea that a timestamp must be a reflection of a count of seconds, though in fact goo.gl/QWsOo a timestamp is simply a sequence of characters or encoded information. In other words, the string "1 Jan 2050, 00:00:00" is in fact a UTC timestamp by itself if we can decode it to the UTC time "1 Jan 2050, 00:00:00". If you don't like alphanumerics, we can always convert this to any arbitrary encoded integer like "2498729866093" and it's still a UTC timestamp as long as the receiver........
– Pacerier
Jun 21 '13 at 2:21
2
2
I've deleted my comments. You win. If you want to learn, start by learning about probability distributions.
– jfs
Oct 30 '14 at 9:19
I've deleted my comments. You win. If you want to learn, start by learning about probability distributions.
– jfs
Oct 30 '14 at 9:19
|
show 15 more comments
Since both of the other answers contain lots of misleading information, I'll throw this in.
Thomas is right that the number of Unix Epoch timestamp seconds per day are fixed. What this means is that on days where there is a leap second, the second right before midnight (the 61st second of the UTC minute before midnight) is given the same timestamp as the previous second.
That timestamp is "replayed", if you will. So the same unix timestamp will be used for two real-world seconds. This also means that if you're getting fraction unix epochs, the whole second will repeat.
X86399.0, X86399.5, X86400.0, X86400.5, X86400.0, X86400.5, then X86401.0.
So unix time can't unambiguously represent leap seconds - the leap second timestamp is also the timestamp for the previous real-world second.
answered Jan 1 at 22:37
B TB T
28.3k25136166
add a comment |
Since both of the other answers contain lots of misleading information, I'll throw this in.
Thomas is right that the number of Unix Epoch timestamp seconds per day are fixed. What this means is that on days where there is a leap second, the second right before midnight (the 61st second of the UTC minute before midnight) is given the same timestamp as the previous second.
That timestamp is "replayed", if you will. So the same unix timestamp will be used for two real-world seconds. This also means that if you're getting fraction unix epochs, the whole second will repeat.
X86399.0, X86399.5, X86400.0, X86400.5, X86400.0, X86400.5, then X86401.0.
So unix time can't unambiguously represent leap seconds - the leap second timestamp is also the timestamp for the previous real-world second.
answered Jan 1 at 22:37
B TB T
28.3k25136166
add a comment |
Since both of the other answers contain lots of misleading information, I'll throw this in.
Thomas is right that the number of Unix Epoch timestamp seconds per day are fixed. What this means is that on days where there is a leap second, the second right before midnight (the 61st second of the UTC minute before midnight) is given the same timestamp as the previous second.
That timestamp is "replayed", if you will. So the same unix timestamp will be used for two real-world seconds. This also means that if you're getting fraction unix epochs, the whole second will repeat.
X86399.0, X86399.5, X86400.0, X86400.5, X86400.0, X86400.5, then X86401.0.
So unix time can't unambiguously represent leap seconds - the leap second timestamp is also the timestamp for the previous real-world second.
answered Jan 1 at 22:37
B TB T
28.3k25136166
Since both of the other answers contain lots of misleading information, I'll throw this in.
Thomas is right that the number of Unix Epoch timestamp seconds per day are fixed. What this means is that on days where there is a leap second, the second right before midnight (the 61st second of the UTC minute before midnight) is given the same timestamp as the previous second.
That timestamp is "replayed", if you will. So the same unix timestamp will be used for two real-world seconds. This also means that if you're getting fraction unix epochs, the whole second will repeat.
X86399.0, X86399.5, X86400.0, X86400.5, X86400.0, X86400.5, then X86401.0.
So unix time can't unambiguously represent leap seconds - the leap second timestamp is also the timestamp for the previous real-world second.
answered Jan 1 at 22:37
B TB T
28.3k25136166
answered Jan 1 at 22:37
B TB T
28.3k25136166
answered Jan 1 at 22:37
B TB T
28.3k25136166
answered Jan 1 at 22:37
B TB T
28.3k25136166
28.3k25136166
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f16539436%2funix-time-and-leap-seconds%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
7
There's a nice recap of utc/tai at madore.org/~david/computers/unix-leap-seconds.html
– loreb
May 15 '13 at 14:23
1
This page explains how OSes deal/should deal with leap second information from ntp, meinbergglobal.com/english/info/leap-second.htm#os
– Silver Moon
Jan 28 '17 at 12:53