GWRon
commented
1 year ago I think one issue is in bmx_datetime_to_epoch():
It simply ignores any "offset" (timezone?) when converting. It assume that whatever is stored "inside" is already UTC.
https://linux.die.net/man/3/mktime:
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.
Means there are 3 options for "isdst": 0 -> no daylight savings time in use 1 -> use it -1 -> let databases decide if at the given time DST was active or not.
In bmx_datetime_from_epoch() the current code simply sets dt.dst = 0; in all cases. Means no matter what time we pass, it says "nope, no DST that time".
I now changed that to dt.dst = -1; and the output of the original example above shows a diff of "-2 hours" between each of the three lines. Same happens when telling dt.dst = 1;. So it correctly identified my filestamps to be during "DST" times (and that my computer is in an area having DST at all).
BTW - alternative Test:
SuperStrict
Framework Brl.StandardIO
Import Pub.stdc
Local now:SDateTime
now.year = 2023
now.month = 7
now.day = 4
now.utc = 1
print "now : " + now.ToString() + " " + now.ToEpochSecs()
print "test: " + SDateTime.FromEpoch(now.ToEpochSecs()).ToString() +" " + SDateTime.FromEpoch(now.ToEpochSecs()).ToEpochSecs()Output:
now : 2023-07-04T00:00:00Z 1688425200
test: 2023-07-03T23:00:00Z 1688421600(so ToString() seems to be correct, but ToEpoch + FromEpoch results in an incorrect value)
(when setting dt.isdst = -1; in bmx_datetime_from_epoch() then the second line becomes test: 2023-07-03T23:00:00Z 1688418000 - so 3600seconds less but the ToString() "correctly" (but still off by an hour) stays the same as with isdst = 0;)
Mr. Easyware at discord brought up an issue with setting a just read modified file time as modified file time of another file leading to time differences. In their case it was 8 hours -- and as I think they is an Asian user I think it is the time zone influencing it.
I made this sample - and in my case the difference is -1, Germany is "+2" to UTC (but guess DST ...)
Save this next to a freshly created "text.txt" (yeah, too lazy to create a file :D)
Output here:
I assume the issue is that "writing" contains information about eg. DST. But once you only have the "epoch seconds" and want to convert them back into a SDateTime, that information is lost. This would explain the offset by "-1" in my case. But I am not sure about the 8hrs difference the user reported at discord.