lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Fri, Feb 11, 2022 at 3:16 PM Dirk Jagdmann <doj@cubic.org> wrote:
trying to get the integer timestamp value for 1969-12-31T23:59:59 fails,
as the implementation in os_time() can not distinguish it from a
different error of the mktime() function. Of course this is clearly an
issue with the c library's function signature of "time_t mktime(struct
tm*)" , but would it be possible to work around this in Lua?

Here's a man page for mktime (and friends): https://linux.die.net/man/3/mktime

The relevant part is:

The mktime() function converts a broken-down time structure, expressed as local time, to calendar time representation. The function ignores the values supplied by the caller in the tm_wday and tm_yday fields. The value specified in the tm_isdst field informs mktime() whether or not daylight saving time (DST) is in effect for the time supplied in the tm structure: a positive value means DST is in effect; zero means that DST is not in effect; and a negative value means that mktime() should (use timezone information and system databases to) attempt to determine whether DST is in effect at the specified time.

The mktime() function modifies the fields of the tm structure as follows: tm_wday and tm_yday are set to values determined from the contents of the other fields; if structure members are outside their valid interval, they will be normalized (so that, for example, 40 October is changed into 9 November); tm_isdst is set (regardless of its initial value) to a positive value or to 0, respectively, to indicate whether DST is or is not in effect at the specified time. Calling mktime() also sets the external variable tzname with information about the current timezone.

If the specified broken-down time cannot be represented as calendar time (seconds since the Epoch), mktime() returns (time_t) -1 and does not alter the members of the broken-down time structure.

So the key to detecting this, I think, is that the caller-supplied values in tm_wday and tm_yday are ignored and overwritten on success, but are unmodified on failure. Therefore, it may be possible to distinguish a -1 error case from a "last second of 1969" case by placing an out-of-range "canary" value in one of those fields before the call to mktime. If a -1 is returned, then check for the canary value, and throw the Lua error if present, otherwise if the canary value is gone, then the -1 return is legitimate.

Of course, one should consider this comp.std.c thread from 1997 as well: https://groups.google.com/g/comp.std.c/c/_dmzHOyuhA0/m/7Vsxzqj49EIJ Clearly, this has been a known problem for at least 25 years.