View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0035710||FPC||RTL||public||2019-06-12 16:07||2020-11-23 08:20|
|Reporter||Ondrej Pokorny||Assigned To||Ondrej Pokorny|
|Summary||0035710: DateToISO8601 returns wrong result if summertime and wintertime differ|
|Description||If summertime and wintertime differ (like it is in central Europe), DateToISO8601 returns a datetime with wrong timezone offset for the other time different from Now.|
|Steps To Reproduce||program Project1;|
uses SysUtils, DateUtils;
Writeln(DateToISO8601(IncMonth(Now, 6), False));
Tested on 2019-06-12:
Delphi returns: 2019-12-12T16:01:43.00+01:00 (correct)
FPC returns: 2019-12-12T16:01:43.000+02:00 (wrong)
|Additional Information||DateToISO8601 uses GetLocalTimeOffset that is not DateTime-aware. It must be made DateTime aware because the offset can vary during the year.|
|Tags||No tags attached.|
|Fixed in Revision||r47206, r47290|
Delphi has the TTimeZone abstract class for it: http://docwiki.embarcadero.com/Libraries/Tokyo/en/System.DateUtils.TTimeZone
in particular the GetUtcOffset:
||Fixed for Windows in r47206|
Yes, Windows has the lookup table built in, that is, until the next patch. UNIX 's and derivitaves, including Linix and the BSD's too:
But there are problems....."just" a few....
E.g. Spain has next year UTC, not UTC+1...... Windows has not patched this yet. Reason: see below and Barcelona has almost the same longitude as London .
E.g. EU is busy skipping Winter/summertime altogether.
E.g. Even on Windows Western Samoa has the wrong local time zone. (US territory)
The same goes for Linux: this is a maintenance intensive interface on all platforms.
I suggest to let it to the OS's because of that: time zones are politically defined. Maintenance pressure to keep up with these upcoming changes do not belong in the compiler or the RTL.
If you do not rely on the OS and its updates, next year such a patch will not work at all. A programmer always works with UTC.
Get the problem?
In the case of Windows there is even a difference between on-line and off-line as I happened to notice when time zone needs to change and there is no internet connection.
The best cross platform scenario is to let this function depend on global time servers. I missed that in the patch?
The best we can do is to rely on what the OS provides us with. We do not want to reinvent this wheel. At least if the OS has the wrong information, then FPC will be consistent with what the OS displays and that is what is important.
Also the RTL will not depend on network functionality like that.
Exactly what I mean. Leave it to the OS. Also note this will never work for platforms that do not have an internal clock like the Raspberry Pi which relies on the Internet or a clock HAT.
||Thaddy, you are the best of best of best!|
||Fixed also for Linux.|
|2019-06-12 16:07||Ondrej Pokorny||New Issue|
|2019-06-12 16:11||Ondrej Pokorny||Note Added: 0116694|
|2020-10-26 13:29||Ondrej Pokorny||Fixed in Revision||=> r47206|
|2020-10-26 13:29||Ondrej Pokorny||FPCTarget||=> -|
|2020-10-26 13:29||Ondrej Pokorny||Note Added: 0126567|
|2020-10-26 19:27||Thaddy de Koning||Note Added: 0126572|
|2020-10-26 19:30||Thaddy de Koning||Note Edited: 0126572||View Revisions|
|2020-10-26 19:32||Thaddy de Koning||Note Edited: 0126572||View Revisions|
|2020-10-26 19:37||Thaddy de Koning||Note Edited: 0126572||View Revisions|
|2020-10-27 09:52||Sven Barth||Note Added: 0126578|
|2020-10-27 14:21||Thaddy de Koning||Note Added: 0126582|
|2020-10-27 14:23||Thaddy de Koning||Note Edited: 0126582||View Revisions|
|2020-10-27 14:26||Thaddy de Koning||Note Edited: 0126582||View Revisions|
|2020-10-27 17:22||Ondrej Pokorny||Note Added: 0126585|
|2020-11-03 12:46||Ondrej Pokorny||Fixed in Revision||r47206 => r47206, r47290|
|2020-11-23 08:20||Ondrej Pokorny||Assigned To||=> Ondrej Pokorny|
|2020-11-23 08:20||Ondrej Pokorny||Status||new => resolved|
|2020-11-23 08:20||Ondrej Pokorny||Resolution||open => fixed|
|2020-11-23 08:20||Ondrej Pokorny||Note Added: 0127129|
|2020-11-23 08:20||Ondrej Pokorny||Status||resolved => closed|