These leap seconds are a PITA ;-)
It probably depends upon what you define as being "one hour after":
- 3,600 seconds later or
- 1 hour later, but minutes and seconds identical.
The unix time_t counts seconds since the epoch.
Yes and no. It defines "seconds since the epoch" differently than a
phycisist would. In
http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_15
the explicit formula for converting calendar time (in UTC) into "seconds
since the epoch" is given, and it doesn't allow for leap seconds. This
is not an oversight, the text confirms:
| How any changes to the value of seconds since the Epoch are made to
| align to a desired relationship with the current actual time is
| implementation-defined. As represented in seconds since the Epoch, each
| and every day shall be accounted for by exactly 86400 seconds.
While I admit that the language of that section isn't as clear as the
formula, the fact is that all POSIX implementations implement the
formula as given and agree that 2008-01-01T00:00:00Z is 1199145600
"seconds since the epoch" and 2009-01-01T00:00:00Z is 1230768000
"seconds since the epoch", while in the real world there were 31622401
seconds between these two times, not 31622400.
Because "seconds since the epoch" are not really seconds since the epoch
in the physical sense I avoid the term and talk about a "POSIX time_t
value" instead.
However, once you try to convert this into a human readable time
onvolving years, months, days, hours, minutes, seconds, you *do* need
to know leap days and seconds to do that.
You need to know about leap days of course, but these are fixed.
You do not need to know about leap seconds, since they aren't used in
this conversion. However, you do need to know about them for an accurate
implementation of difftime(). Strictly speaking,
difftime(1230768000, 1199145600) should return 31622401.0, but I doubt
there is any implementation which does.
So, if you happen to want to know the time and date of *exactly* 1 hour
after *exactly* 11pm on the 31st of december 2008, the answer depends
upon the fact that 2008 had a leap second appended to the last minute of
the year!
If you just added 3,600 seconds to the time_t value of 12/31/2008
11:00:00pm, then you'd end up at 12/31/2008 11:59:60pm.
Yes, but there is no time_t value corresponding to that time: 1230767999
is 2009-12-31T23:59:59Z, and 1230768000 is 2009-01-01T00:00:00Z by
definition!
time_t value is implementation defined.
But I must admit, this doesn't even help *me* and I'm not even sure any
more that I am helping.
Just ignore leap seconds unless you need to make time measurements which
cannot tolerate a one second error. For "normal" calendar time keeping
you don't need to know about them.
However, daylight savings time is quite a different matter.
hp