struct tm -> time_t converter wanted

[Doug Gwyn]

In article <13422 at cisunx.UUCP> cmf at unix.cis.pittsburgh.edu (Carl M. Fongheiser) writes:
>In article <8754 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>>In article <12418 at steinmetz.ge.com> davidsen at crdos1.UUCP (bill davidsen) writes:
>>>changing the epoch or going to 64 bits would break existing programs.
>>Neither will break existing correct programs that don't assume things
>>not promised by the specifications.
>Excuse me?  The last time I checked, the man page for time(3) (time(2)
>in the V7 man pages) clearly stated that the return value was the number
>of seconds since 00:00:00 GMT, January 1 1970.  Not having an SVID handy
>(or a POSIX spec, for that matter), I can't say anything authoritative
>about them.  But if I write a program that knows about that epoch, I'm
>violating the rules?

For C (without additional requirements imposed by SVID, POSIX, etc.),
time_t is just an arithmetic type with the time somehow encoded in it.
It is not guaranteed to use the same encoding from one program
execution to the next, so it permits moving the Epoch when necessary.
There is a macro CLK_TCK for converting between seconds of duration
and the difference of two values returned by clock(), but the origin
is not specified (it may, for example, be the beginning of program
execution).

Since this discussion is occurring in the C newsgroup, not the UNIX one,
you are definitely outside the scope of the specs for the meaning of
time_t if you assume that it means "seconds since the beginning of 1970
AD at Greenwich".  IEEE 1003.1-1988 (POSIX) imposes that additional
requirement, but they also don't require that time conversion from
time_t to/from struct tm be done accurately.  In fact POSIX requires
that it be done inaccurately whenever a leap second is involved!  As far
as ANSI C is concerned, that inaccuracy might be considered a (poor)
"quality of implementation" issue.  Certainly converting future times
to/from whatever Congress mandates cannot guarantee accuracy.