On Wed, Jul 27, 2022 at 12:26 PM Cottrell, Allin <cottrell(a)wfu.edu> wrote:
On Wed, Jul 27, 2022 at 12:04 PM <kzstatis(a)gmail.com> wrote:
>
> > -----Oorspronkelijk bericht-----
> > Van: Cottrell, Allin
> > ...
> > 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.
>
> I think on MS Windows time_t is also a signed integer (int64); see
>
https://docs.microsoft.com/en-us/cpp/c-runtime-library/standard-types?vie...
> Also, mktime could not have -1 as a return value if time_t was unsigned.
> Rather it's the implementation that refuses to deal with dates before 1-1-1970;
see
>
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/mktime-m...
Thanks for the correction. So it looks as if we can fix the issue on
Windows by calling _mktime64() instead of plain mktime().
No, I misunderstood the Microsoft doc. In fact mktime() calls
_mktime64() by default. Regardless of the signedness or width of
time_t on Windows, their mktime function(s) refuse to return anything
other than -1 for dates prior to 1970. Tant pis!
Although some of what I said here previously was wrong, I believe the
new text in the documentation for gretl's strptime() and strftime(),
regarding the limitations of MS Windows, is correct.
In principle we might think of substituting our own implementation of
mktime() on Windows, but this is a decidedly non-trivial function.
Allin