In message 072220051459.22583.42E109DB0000A128000058372205884484050E999B9A049D@comcast.net, rlutwak@comcast.ne
t writes:

The leapsecond support is not enabled by default because that would break POSIX.

I belive the common source of all this is something called "tzdata" from
Arthur David Olson, and the leapsecond support is a feature of that code.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

offers any support?  And if not, how do they keep the system from breaking
down do to inconsistencies between forward and backward calculations between
tm* and time_t ?

Robert,

Windows implements time_t the same way as many
platforms - time_t is simply a 32-bit integer "encoding"
for date and time. Days are t / 86400 since 1970 with
standard leap year rules and time is t % 86400 with
no leap second support. The native 100 ns granularity
kernel time functions upon which time_t is built are
no different.

Doug may have something to add here (he wrote
Windows timeserv).

I worked on the Windows NT operating system in
the 90's and on occasion did full source code
searches for leap seconds and related time topics.
As far as I recall, at the time, there was no leap
second support at all. This meant that Windows
timekeeping worked pretty much the same as any
BIOS, PDA, wristwatch, wall clock, desk clock,
car clock, thermostat, or VCR; namely, it keeps
adequate time and you re-set it when it's off by
too much. Windows does have timezone and
programmed DST support for the functions that
report local time.

I don't know about XP or Longhorn; perhaps someone
else will have more up-to-date information.

/tvb
http://www.LeapSecond.com/pages/unix/

In message 002c01c58ef2$567d28c0$5e12f204@computer, "Tom Van Baak" writes:

There is an open issue according to M$:

http://support.microsoft.com/default.aspx?scid=kb;en-us;246145

In the earlier version, there was a delay in insertion of
a leap second through a multi-tiered environment, although
this delay did not occur in every instance. The TimeServ
utility currently does not schedule the insertion for the
exact moment at midnight. Instead, TimeServ inserts the
second at the first synchronization after the source time
has adjusted, and then logs the event.

In a tiered environment, the leap second may be inserted
in the following order:

1.	On the master server.
2.	When any primary machines request the time from the master.
3.	When any secondary machines request the time from a primary.

For types that warn of a coming leap second, the TimeServ
utility
optimizes the synchronization time to be shortly after the moment
of leap second insertion.

The synchronization occurs with certain allowances for
randomization
in order to spread potential overloading at individual servers, and
delays due to tiered structure. The TimeServ utility tries to
resynchronize all machines within 15 minutes of the leap second.

As I read this, leapseconds sort of trickle out from the timeservers
to the client in whatever time it takes.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.