[tz] [PATCH] Introduce Epoch offset and local time Epoch
Guy Harris
guy at alum.mit.edu
Wed Oct 26 07:06:56 UTC 2016
On Oct 21, 2016, at 6:21 PM, Paul Eggert <eggert at cs.ucla.edu> wrote:
> On 10/21/2016 06:00 PM, Guy Harris wrote:
>> Should there be a comment
>
> Yes, it appears so. How about the attached?
It looks good, although the documentation of the purpose of that code appears to be split between the comment in localtime.c:
/* Convert from the underlying system's time_t to the ersatz time_tz,
which is called 'time_t' in this file. Typically, this merely
converts the time's integer width. On some platforms, the system
time is local time not UT, or uses some epoch other than the POSIX
epoch.
Although this code appears to define a function named 'time' that
returns time_t, the macros in private.h cause this code to actually
define a function named 'tz_time' that returns tz_time_t. The call
to sys_time invokes the underlying system's 'time' function. */
and the comment in private.h:
/*
** Compile with -Dtime_tz=T to build the tz package with a private
** time_t type equivalent to T rather than the system-supplied time_t.
** This debugging feature can test unusual design decisions
** (e.g., time_t wider than 'long', or unsigned time_t) even on
** typical platforms.
*/
So:
1) Is this only a debugging feature?
2) Is it intended only to be used on platforms that provide a native time() call and only to map that result to a seconds-since-the-Un*x-Epoch value of a specified integral type (which might not be the OS's time_t type, so it could be used even on UN*X), rather than to be used as a wrapper around whatever the OS's "native" "what's the current date and time of day" API is?
If 1) isn't (is no longer?) true, the comment in private.h should probably be updated.
If 2)
More information about the tz
mailing list