84 lines
3.3 KiB
Text
84 lines
3.3 KiB
Text
|
NAME
|
||
|
|
|
||
|
|
time2posix, posix2time - convert seconds since the Epoch
|
||
|
|
|
||
|
|
SYNOPSIS
|
||
|
|
#include <sys/types.h>
|
||
|
|
#include <time.h>
|
||
|
|
|
||
|
|
time_t time2posix(t)
|
||
|
|
time_t t
|
||
|
|
|
||
|
|
time_t posix2time(t)
|
||
|
|
time_t t
|
||
|
|
|
||
|
|
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.
|
||
|
|
|
||
|
|
SEE ALSO
|
||
|
|
difftime(3), localtime(3), mktime(3), time(2)
|