File modification time is wrong for half the year (especially in Linux)

[daniels220]

If I have a file with a mod date when DST is not active, and when DST is active I ask a FileReference to that file for its modificationTime, the answer I get is an hour off. For instance:

$ touch -d '2024-02-01 12:34:56pm' nondst.txt
$ stat -c '%y' nondst.txt
2024-02-01 12:34:56.000000000 -0500
$ touch -d '2023-06-01 12:34:56pm' withdst.txt
$ stat -c '%y' withdst.txt
2023-06-01 12:34:56.000000000 -0400

Then in Pharo on Unix (DST is currently active):

'nondst.txt' asFileReference modificationTime. "=> 2024-02-01T12:34:56-04:00"
'withdst.txt' asFileReference modificationTime. "=> 2023-06-01T12:34:56-04:00"

and on Windows (same files—I used a network share):

'nondst.txt' asFileReference modificationTime. "=> 2024-02-01T13:34:56-04:00"
'withdst.txt' asFileReference modificationTime. "=> 2023-06-01T12:34:56-04:00"

In other words, Linux Pharo is using the current local offset for all times, even those to which a different offset applies, in such a way that it actually changes the UTC time. Meanwhile Windows Pharo is...well, Windows has the same bug of using the current offset for everything, so in this case Pharo is doing the best it can, I suppose. At least the equivalent UTC time is right, even if the offset is wrong.

Looking at the FileAttribute plugin code...I think there's legacy cruft going on here—file attributes are the only things that use DateAndTime class>>fromInternalTime:, and the current DateAndTime implementation uses a different representation such that calling that "internal time" is no longer really accurate. Probably the old implementation predates support for timezone offsets—at this point I think the correct approach would be for the primitive to return a two-element array of {UTC seconds since UNIX epoch. Offset seconds from UTC (as determined by localtime(&unixTime)->tm_gmtoff)} and go from there doing remaining calculation in the image. This way at least the UTC time would always be right, and the offset would be correct on Unix and wrong on Windows (but that's normal for Windows, and with the right UTC time application code could choose to recompute the offset if desired).

On a related note, I see that not all implementations will include tm_gmtoff, in which case we use a fallback based on a magically-declared variables. But this is going to have the same problem of using the same offset all year rather than the correct one for whatever time of year it is. AFAICT all implementations should include a tm_isdst member, and if we replaced daylight with localtime(&unixTime)->tm_isdst it should then be accurate.