[PATCH] Introduce Epoch offset and local time Epoch
--- localtime.c | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/localtime.c b/localtime.c index 6c00c45..3465248 100644 --- a/localtime.c +++ b/localtime.c @@ -58,6 +58,15 @@ static void unlock(void) { } #define OPEN_MODE O_RDONLY #endif /* !defined O_BINARY */ +/* +** AmigaOS Epoch is local time January 1, 1978 +*/ + +#ifdef AMIGAOS +#define TZEPOCH_OFFSET -252460800 +#define TZLOCAL_EPOCH 1 +#endif /* defined AMIGAOS */ + #ifndef WILDABBR /* ** Someone might make incorrect use of a time zone abbreviation: @@ -118,6 +127,12 @@ struct lsinfo { /* leap second information */ #ifndef TZNAME_MAX #define MY_TZNAME_MAX 255 #endif /* !defined TZNAME_MAX */ +#ifndef TZEPOCH_OFFSET +#define TZEPOCH_OFFSET 0 +#endif /* !defined TZEPOCH_OFFSET */ +#ifdef TZLOCAL_EPOCH +#define ALTZONE 1 +#endif /* defined TZLOCAL_EPOCH */ struct state { int leapcnt; @@ -2262,7 +2277,12 @@ posix2time(time_t t) time_t time(time_t *p) { - time_t r = sys_time(0); + time_t r = sys_time(0) + TZEPOCH_OFFSET; +#ifdef TZLOCAL_EPOCH + if(lcl_is_set) { + r += (!daylight ? timezone : altzone); + } +#endif if (p) *p = r; return r; -- 2.7.4
Thanks, how about the attached patch instead? It lets you specify an arbitrary gmtime offset instead of hardwiring it for the Amiga. You should be able to build it on the Amiga with something like "make CFLAGS='-DEPOCH_LOCAL -DEPOCH_OFFSET=252460800'".
On Oct 21, 2016, at 5:32 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
Thanks, how about the attached patch instead? It lets you specify an arbitrary gmtime offset instead of hardwiring it for the Amiga. You should be able to build it on the Amiga with something like "make CFLAGS='-DEPOCH_LOCAL -DEPOCH_OFFSET=252460800'".
So what is the purpose of time() in tzcode? Presumably it serves *some* purpose on UN*X or other OSes that supply the UN*X time() API. Should there be a comment explaining what purpose it serves on OSes that have a UN*X-compatible time() API and indicating that it can be used on OSes that don't and how it should be used.
On Oct 21, 2016, at 6:21 PM, Paul Eggert <eggert@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)
Guy Harris wrote:
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.
The "debugging feature" is when you compile with -Dtime_tz=T. Substituting the 'time' function is done either because this debugging feature is enabled, or because you're on a system where the epoch is localtime or doesn't use 1970. The comment in private.h is only about the debugging feature. The comment in localtime.c is about substituting the 'time' function. Perhaps the wording in the two comments could be improved....
On 10/22/2016 02:32, Paul Eggert wrote:
Thanks, how about the attached patch instead? It lets you specify an arbitrary gmtime offset instead of hardwiring it for the Amiga. You should be able to build it on the Amiga with something like "make CFLAGS='-DEPOCH_LOCAL -DEPOCH_OFFSET=252460800'".
There are several implementations of the Standard C library time() function for AmigaOS and none of them are consistent. To utilize this patch a direct call to the well documented and consistent AmigaOS function GetSysTime() would be required. This should be done in the LOCALTIME_IMPLEMENTATION define in private.h. # ifdef LOCALTIME_IMPLEMENTATION static time_t sys_time(time_t *x) { return time(x); } # endif I don’t know how to supply this information in a correct manner but it should probably be incorporated in the Makefile. Otherwise, the patch looks correct. I will need to do more testing on affected platforms. Kind regards Carsten Larsen
Carsten Larsen wrote:
There are several implementations of the Standard C library time() function for AmigaOS and none of them are consistent. To utilize this patch a direct call to the well documented and consistent AmigaOS function GetSysTime() would be required.
I don't see how that could work, as the epoch for GetSysTime is power-on, not any fixed date. Anyway, that sort of fooling around with OS internals should be out of scope for the tz project. If what's already in tzcode suffices for the particular time() implementation you're linking to, that should be good enough.
On Wed, Oct 26, 2016, at 01:58, Paul Eggert wrote:
I don't see how that could work, as the epoch for GetSysTime is power-on,
It's *set* to 0 at power on, but all indications seem to be that the *intended meaning* is "seconds since 1978" For example, the sentence "The system starts out at time "zero" so it is safe to set it forward to the real time." wouldn't make sense if there weren't a notion of "the real time" independent of power-on.
On Oct 25, 2016, at 11:42 PM, Random832 <random832@fastmail.com> wrote:
On Wed, Oct 26, 2016, at 01:58, Paul Eggert wrote:
I don't see how that could work, as the epoch for GetSysTime is power-on,
It's *set* to 0 at power on, but all indications seem to be that the *intended meaning* is "seconds since 1978"
I.e., like some (older) UN*Xes, except that it's *documented* as starting as 0 at power-on, rather than "starting at 0" being the result of the current time value in the kernel being in a variable in the kernel's BSS space or something such as that. (Even older UN*Xes set it to the last modified time of /, or something else from the file system, as soon as the root file system was mounted, as I remember, so the clock wasn't *quite* off. Most if not all UN*Xes, these days, run on hardware with some flavor of time-of-day clock that continues counting during a reboot and may even have a battery so that it continues counting even if the power is turned off, and a value taken from that gets used as the current time value. It's been so long since I've used such a system - did we *really* have to log in as root and type the "date" command after a reboot if we wanted the system's clock to be sufficiently close to reality?)
Guy Harris wrote:
did we *really* have to log in as root and type the "date" command after a reboot if we wanted the system's clock to be sufficiently close to reality?)
Yes. How quickly we forget! But here's a confirming source, which says, "After booting unix, the current date and time (date (1)) must be set": http://www.tuhs.org/Archive/PDP-11/Distributions/dec/Jean_Huens_v7m/setup.tx...
On Wed, Oct 26, 2016, at 03:12, Guy Harris wrote:
Most if not all UN*Xes, these days, run on hardware with some flavor of time-of-day clock that continues counting during a reboot and may even have a battery so that it continues counting even if the power is turned off, and a value taken from that gets used as the current time value. It's been so long since I've used such a system - did we *really* have to log in as root and type the "date" command after a reboot if we wanted the system's clock to be sufficiently close to reality?)
I'm too young to know how things were on the ground for Unix systems, but, PDP-11 Unix boots into a root prompt on the console and you have to Ctrl-D out of the shell to continue to go on to multi-user mode, and V7 boot(8) mentions "doing any filesystem checks and setting the date" as the purpose. I do remember that on MS-DOS, the system automatically prompted for the date and time after every boot, before giving you the command prompt.
On Oct 26, 2016, at 6:17 AM, Random832 <random832@fastmail.com> wrote:
I'm too young to know how things were on the ground for Unix systems, but, PDP-11 Unix boots into a root prompt on the console and you have to Ctrl-D out of the shell to continue to go on to multi-user mode, and V7 boot(8) mentions "doing any filesystem checks and setting the date" as the purpose.
Speaking of behaviors from so long ago that I no longer remember them....
participants (4)
-
Carsten Larsen -
Guy Harris -
Paul Eggert -
Random832