DateTime accounts for leap seconds ?!

[nriesch]

In the documentation, the "Second" property of class
DateTime is a value between 0 and 59.

In UTC time, approximately every year of so, a leap
second is added at 00:00:00 UTC, so as to account for the
irregular rotation of the earth, which is slowing down a
little bit.
So, a minute can contains 61 seconds ( range 0..60 ).
Besides, the NTP protocol takes leap second into account,
and UTC time also.

Is it possible for DateTime to return 60 for the "Second"
property ?
Does it depends on the underlying OS ?
Or does a minute always contains 60 seconds for the class
DateTime ? ( which means an interval of time can be
physically 11 seconds long, even if the difference
computed from Datetime values is 10 seconds only, if a
leap second occurs in-between )...

Any suggestion ?

[Juan Gabriel Del Cid]

There are always 60 seconds in a minute, 60 minutes in an hour, 24 hours in
a day... *always*. There is no "leap second" added at any time or any place
on earth. What happens is that it take the earth's 365.2422 days to do a
complete revolution around the sun. Here's where the fun starts.

Leap *days* are needed to keep our callendar aligned with the earth's motion
around the sun. Bear in mind I said days... whole, complete days. There's a
whole set of rules as to how you calculate whether or not a year has a leap
day added or not (http://www.timeanddate.com/date/leapyear.html).

So, of course, DateTime seconds account only for the 60 possible seconds of
a minute (ranging from 0..59, as you pointed out).

-JG

[nriesch]

There are always 60 seconds in a minute, 60 minutes in an hour, 24 hours ina day... *always*. There is no "leap second" added at any time or any placeon earth.

I know, leap seconds are a pain in the ass. When someone
use a time library, he must know the conditions in which
he can use it. I mean, if the library handles leap
seconds, and how it copes with them. The number of ticks
for a given date could change if leap seconds are
accounted for.

UTC is now quite the reference for civil time, and it is
based on atomic clock, more accurate than the period of
rotation of earth, which varies slightly and is not as
periodic as it should be.

From http://www.npl.co.uk/time/leap_second.html, we have
an example:
1998 December 31 23h 59m 58s
1998 December 31 23h 59m 59s
1998 December 31 23h 59m 60s (here, leap second inserted)
1999 January 01 00h 00m 00s
1999 January 01 00h 00m 01s

In C and Java, and certainly lots of other languages,
leap seconds are taken into account, if the underlying OS
support it.

Quoting from the Java Language Specification about class
java.util.Date:
"A second is represented by an integer from 0 to 61. The
values 60 and 61 will occur only for leap seconds, and
even then only in Java implementations that actually
track leap seconds correctly. Because of the manner in
which leap seconds are currently introduced, it is
extremely unlikely that two leap seconds will occur in
the same minute, but this specification follows the date
and time conventions for ISO C."

Same problem about C. Quoting from any libc reference:
struct tm: This is the data type used to represent a
broken-down time.
int tm_sec: This is the number of full seconds since the
top of the minute (normally in the range 0 through 59,
but the actual upper limit is 60, to allow for leap
seconds if leap second support is available).

http://tycho.usno.navy.mil/leapsec.html
http://www.leapsecond.com/java/gpsclock.htm

Any other suggestion ?

[nriesch]

In the doc for .NET Framework Class Library, in msdn
library, I read:

DateTime Structure:
Descriptions of time values in this type are often
expressed using the coordinated universal time (UTC)
standard, which was previously known as Greenwich mean
time (GMT).

DateTime.UtcNow Property:
Gets a DateTime that is the current local date and time
on this computer expressed as the coordinated universal
time (UTC).

DateTime.Second Property:
The seconds, between 0 and 59.

DateTime.Ticks Property:
The value of this property is the number of 100-
nanosecond intervals that have elapsed since 12:00 A.M.,
January 1, 0001.

---------------

Those specifications are totally incoherent.

1) UTC is based on atomic clock, and includes leap
seconds.
A minute in UTC time can thus be 59, 60, 61, 62
seconds long.

2) If DateTime.UtcNow returns a DateTime as UTC, then the
minute property of the returned value can be 59, 60, 61,
or 62 seconds, because UTC time includes leap seconds. If
not, the returned value is not UTC time.

3) If DateTime.Second property only ranges from 0 to 59,
then Datetime is not really UTC time.

4) UTC is based on atomic clock, GMT is based on earth
rotation. It is absolutely not the same thing.

5) DateTime.Ticks returns the number of ticks, but
following which standard. UTC ?

Someone can clarify all this mess ?
Does the behaviour of DateTime depends on the underlying
system ? or on the implementation of .NET library ?

thanks