Leap second handling
Some operating systems contain a set of "right" time zone files. These files implement a non-conforming variant of POSIX "seconds since the epoch" by assuming that the time_t value returned by time() includes leap seconds. Some system administrators configure their systems to count leap seconds, causing a variety of interoperability problems.
Our implementation now (since [krbdev.mit.edu #6928]) assumes that if gmtime() on a system is capable of accounting for leap seconds (and the system therefore typically includes a set of "right" time zone files), that a corresponding (non-POSIX) timegm() (which is the inverse of gmtime() is available.
If there is ever an operating system that can count leap seconds but lacks timegm() (which is arguably a bug in that OS), we can implement a workaround that replaces gmtime() with one that always ignores leap seconds. (On a system configured with a "right" time zone, this will produce "wrong" GeneralizedTime encodings, ironically enough, that are ahead of actual UTC by the total number of accumulated leap seconds.)
The following information is courtesy of Zihao Jiang of Centrify:
| OS | has "right" zoneinfo | has timegm()
|
|---|---|---|
| Redhat linux 5.2 32bit | Y | Y |
| Ubuntu 10.04 32bit | Y | Y |
| CentOS 5.6 32bit | Y | Y |
| RHEL Server 5.2 64bit | Y | Y |
| SUSE Server 10 32bit | Y | Y |
| Fedora release 13 32bit | Y | Y |
| Debian 4.0 32bit | Y | Y |
| HPUX B.11.23 ia64 | N | N |
| AIX5.1 | N | N |
| SunOS 5.10 sparc | N | N |
| SunOS x86_64 | N | N |
There is some evidence (4.4BSD SMM) that, for some reason, for the 4.4BSD operating system, the UCB CSRG chose a default of counting leap seconds. Modern FreeBSD, and probably the other open-source 4.4BSD derivatives, appear to default to POSIX leap second behavior.
