|
|
Posted by Moe Trin on 06/23/07 19:58
On Sat, 23 Jun 2007, in the Usenet newsgroup comp.os.linux, in article
<09adnZ9Lj6JzNOHbnZ2dnUVZ_segnZ2d@giganews.com>, David T. Ashley wrote:
>I have Red Hat Enterprise Linux 4.
>
>I was just reading up about UTC and leap seconds.
You'll want to look at
-rw-rw-r-- 1 gferg ldp 43295 Nov 18 2005 TimePrecision-HOWTO
TimePrecision-HOWTO, Managing Accurate Date and Time HOWTO
Updated: Nov 2005. Explains the time mechanisms on Linux, what are
time zones, and precision with NTP.
>Is it true on my system that the Unix time may skip up or down by one
>second at midnight when there is a leap second?
No. Your system time will wander along as usual. If you have installed
and configured an NTP _client_ application, your time will _SLEW_ to
make up for the one second error. See the several RFCs that relate to
Network Time, such as
1305 Network Time Protocol (Version 3) Specification, Implementation
and Analysis. D. Mills. March 1992. (Format: TXT=307085, PDF=442493
bytes) (Obsoletes RFC0958, RFC1059, RFC1119) (Status: DRAFT STANDARD)
4330 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and
OSI. D. Mills. January 2006. (Format: TXT=67930 bytes) (Obsoletes
RFC2030, RFC1769) (Status: INFORMATIONAL)
as well as the documentation for your NTP client.
>By "Unix time" I mean the integer returned by time() and similar functions.
time(2) returns seconds since the UNIX epoch. Note that NTP time is
using a different epoch (1/1/1900), but an NTP timestamp really a
truncated NTP date expressed as an unsigned 64-bit integer including the
low order 32 bits of the seconds field concatenated with the high-order
32 bits of the fraction field. This format can represent the 136 years
from 1900 to 2036 with a precision of 232 picoseconds. Ranges beyond
these years require an era number which is the high order 32 bits of the
seconds field of the associated date. Your NTP client corrects for the
difference in epochs when tweaking the time. See
http://www.cis.udel.edu/~mills/y2k.html for more details.
>I'm concerned about the "down" case. Some of the software I've written
>assumes monotonically-increasing time.
So does Professor Mills, who has been in this racket for a "few" years.
If you are interested, you may wish to review recent posts in the Usenet
newgroup 'comp.protocols.time.ntp' which is carried on this news server.
Obviously you aren't concerned with Daylight Saving Time, which has
nothing to do with time(2), or the timestep that occurs when your
system is booting (before client applications start).
Old guy
Navigation:
[Reply to this message]
|