tzcode2012c

1 files changed, 70 insertions, 73 deletions

diff --git a/elsie.nci.nih.gov/src/time2posix.3.txt b/elsie.nci.nih.gov/src/time2posix.3.txt
index 1bcf168..553548f 100644
--- a/elsie.nci.nih.gov/src/time2posix.3.txt
+++ b/elsie.nci.nih.gov/src/time2posix.3.txt
@@ -1,83 +1,80 @@
-NAME
+TIME2POSIX(3)                                                    TIME2POSIX(3)
 
-     time2posix, posix2time - convert seconds since the Epoch
+NAME
+       time2posix, posix2time - convert seconds since the Epoch
 
 SYNOPSIS
-     #include <sys/types.h>
-     #include <time.h>
+       #include <sys/types.h>
+       #include <time.h>
 
-     time_t time2posix(t)
-     time_t t
+       time_t time2posix(t)
+       time_t t
 
-     time_t posix2time(t)
-     time_t t
+       time_t posix2time(t)
+       time_t t
 
-     cc ... -ltz
+       cc ... -ltz
 
 DESCRIPTION
-     IEEE Standard 1003.1 (POSIX) legislates that a time_t value
-     of 536457599 shall correspond to "Wed Dec 31 23:59:59 UTC
-     1986."  This effectively implies that POSIX time_t's cannot
-     include leap seconds and, therefore, that the system time
-     must be adjusted as each leap occurs.
-
-     If the time package is configured with leap-second support
-     enabled, however, no such adjustment is needed and time_t
-     values continue to increase over leap events (as a true
-     `seconds since...' value).  This means that these values
-     will differ from those required by POSIX by the net number
-     of leap seconds inserted since the Epoch.
-
-     Typically this is not a problem as the type time_t is
-     intended to be (mostly) opaque--time_t values should only be
-     obtained-from and passed-to functions such as time(2),
-     localtime(3), mktime(3), and difftime(3).  However, POSIX
-     gives an arithmetic expression for directly computing a
-     time_t value from a given date/time, and the same
-     relationship is assumed by some (usually older)
-     applications.  Any programs creating/dissecting time_t's
-     using such a relationship will typically not handle
-     intervals over leap seconds correctly.
-
-     The time2posix and posix2time functions are provided to
-     address this time_t mismatch by converting between local
-     time_t values and their POSIX equivalents.  This is done by
-     accounting for the number of time-base changes that would
-     have taken place on a POSIX system as leap seconds were
-     inserted or deleted.  These converted values can then be
-     used in lieu of correcting the older applications, or when
-     communicating with POSIX-compliant systems.
-
-     Time2posix is single-valued.  That is, every local time_t
-     corresponds to a single POSIX time_t.  Posix2time is less
-     well-behaved: for a positive leap second hit the result is
-     not unique, and for a negative leap second hit the
-     corresponding POSIX time_t doesn't exist so an adjacent
-     value is returned.  Both of these are good indicators of the
-     inferiority of the POSIX representation.
-
-     The following table summarizes the relationship between a
-     time T and it's conversion to, and back from, the POSIX
-     representation over the leap second inserted at the end of
-     June, 1993.
-     DATE     TIME     T   X=time2posix(T) posix2time(X)
-     93/06/30 23:59:59 A+0 B+0             A+0
-     93/06/30 23:59:60 A+1 B+1             A+1 or A+2
-     93/07/01 00:00:00 A+2 B+1             A+1 or A+2
-     93/07/01 00:00:01 A+3 B+2             A+3
-
-     A leap second deletion would look like...
-
-     DATE     TIME     T   X=time2posix(T) posix2time(X)
-     ??/06/30 23:59:58 A+0 B+0             A+0
-     ??/07/01 00:00:00 A+1 B+2             A+1
-     ??/07/01 00:00:01 A+2 B+3             A+2
-
-                     [Note: posix2time(B+1) => A+0 or A+1]
-
-     If leap-second support is not enabled, local time_t's and
-     POSIX time_t's are equivalent, and both time2posix and
-     posix2time degenerate to the identity function.
+       IEEE Standard 1003.1 (POSIX) legislates that a time_t value of
+       536457599 shall correspond to "Wed Dec 31 23:59:59 UTC 1986."  This
+       effectively implies that POSIX time_t's cannot include leap seconds
+       and, therefore, that the system time must be adjusted as each leap
+       occurs.
+
+       If the time package is configured with leap-second support enabled,
+       however, no such adjustment is needed and time_t values continue to
+       increase over leap events (as a true `seconds since...' value).  This
+       means that these values will differ from those required by POSIX by the
+       net number of leap seconds inserted since the Epoch.
+
+       Typically this is not a problem as the type time_t is intended to be
+       (mostly) opaque--time_t values should only be obtained-from and passed-
+       to functions such as time(2), localtime(3), mktime(3), and difftime(3).
+       However, POSIX gives an arithmetic expression for directly computing a
+       time_t value from a given date/time, and the same relationship is
+       assumed by some (usually older) applications.  Any programs
+       creating/dissecting time_t's using such a relationship will typically
+       not handle intervals over leap seconds correctly.
+
+       The time2posix and posix2time functions are provided to address this
+       time_t mismatch by converting between local time_t values and their
+       POSIX equivalents.  This is done by accounting for the number of time-
+       base changes that would have taken place on a POSIX system as leap
+       seconds were inserted or deleted.  These converted values can then be
+       used in lieu of correcting the older applications, or when
+       communicating with POSIX-compliant systems.
+
+       Time2posix is single-valued.  That is, every local time_t corresponds
+       to a single POSIX time_t.  Posix2time is less well-behaved: for a
+       positive leap second hit the result is not unique, and for a negative
+       leap second hit the corresponding POSIX time_t doesn't exist so an
+       adjacent value is returned.  Both of these are good indicators of the
+       inferiority of the POSIX representation.
+
+       The following table summarizes the relationship between a time T and
+       it's conversion to, and back from, the POSIX representation over the
+       leap second inserted at the end of June, 1993.
+       DATE     TIME     T   X=time2posix(T) posix2time(X)
+       93/06/30 23:59:59 A+0 B+0             A+0
+       93/06/30 23:59:60 A+1 B+1             A+1 or A+2
+       93/07/01 00:00:00 A+2 B+1             A+1 or A+2
+       93/07/01 00:00:01 A+3 B+2             A+3
+
+       A leap second deletion would look like...
+
+       DATE     TIME     T   X=time2posix(T) posix2time(X)
+       ??/06/30 23:59:58 A+0 B+0             A+0
+       ??/07/01 00:00:00 A+1 B+2             A+1
+       ??/07/01 00:00:01 A+2 B+3             A+2
+
+                            [Note: posix2time(B+1) => A+0 or A+1]
+
+       If leap-second support is not enabled, local time_t's and POSIX
+       time_t's are equivalent, and both time2posix and posix2time degenerate
+       to the identity function.
 
 SEE ALSO
-     difftime(3), localtime(3), mktime(3), time(2)
+       difftime(3), localtime(3), mktime(3), time(2)
+
+                                                                 TIME2POSIX(3)