[Gretl-users] Re: strptime() and Win vs Unix
On Fri, Jul 22, 2022 at 3:54 PM Cottrell, Allin <cottrell(a)wfu.edu> wrote:
On Fri, Jul 22, 2022 at 9:10 AM Riccardo (Jack) Lucchetti
<p002264(a)staff.univpm.it> wrote:
>
> a student of mine just let me know that he has problems with the yahoo_get
> package on windows, when it comes to downloading data before 1970. This is
> a consequence of the fact that our strptime() function behaves differently
> on linux and windows. [...]
A little background here. Windows doesn't have strptime(), so libgretl
includes an implementation of it, mostly nabbed from Kungliga Tekniska
Högskolan (Sweden). And It's not strptime that's falling over for
dates prior to 1970. Rather it's mktime(), which is required to
convert the "struct tm" pointer obtained from strptime to "epoch
time"
in seconds.
Sorry, I realize that my reply may be confusing without a little more
info. The gretl function strptime() uses, but is not equivalent to,
the underlying C library function strptime(). The C function (and also
our remedial C implementation for Windows) does not return an "epoch
time" as such. But it makes available a "struct tm" (something that
has no representation in hansl) from which epoch time can be derived
via mktime(). The gretl function then returns the epoch time as a
"scalar".
Unix-type systems treat this epoch time as a signed integer, so
negative offsets relative to midnight of 1969-12-31/1970-01-01 can be
represented. MS Windows treats it as an unsigned integer and so cannot
handle prior dates. If you think about it for a moment, it's clear
that figuring the offset in seconds of a given date from a given
benchmark (the aforementioned start of 1970) is not at all trivial --
think of leap seconds, never mind leap years. So I doubt there's
anything we can do about this other than post a warning.
Allin