Mark Morgan Lloyd
markMLl.fpc-devel at telemetry.co.uk
Tue Nov 17 09:30:04 CET 2015
Zachary Vance wrote:
>>> Additionally, POSIX says that if TZ is set but invalid or empty, it should default to UTC, not to localtime.
>> Observing the contents of the TZ variable is of course an option, that should not be a problem.
>> But the default to localtime will most likely not be changed for 2 reasons
>> a) compatibility with Delphi.
>> b) backwards compatibility.
>> FPC does not pretend to be POSIX.
> I only learnt about the TZ variable investigating this bug and don't know Pascal. That said, this seems to match the page you linked. I'm unclear if the content of literal timezones and timezone files are the same--my local ones on my computer look different, so I'd definitely test to make sure the example strings on the linked page work. If you need someone to test timezone parsing methods because you're not on Linux, try the debian-reproducible IRC. (I'd offer but I don't know fpc at all). You might want to replace '/usr/share/zoneinfo/' by the value of TZDIR if it's defined, for consistency with the rest of fpc?
> If you want to try our original failing test case, which is from Arch Linux but should run on any Linux system:
> 1. Delete /etc/timezone
> 2. Symlink /etc/localtime to your timezone file (not UTC, please)
> 3. Run TZ='' ppadump ... [If you're not modifying things, I guess it would be TZ='UTC']
> Output currently uses the content of /etc/localtime, but should be in UTC.
Obeying TZ sounds reasonable to me, subject to considering the Windows
situation (some unix-style programs on DOS/Windows honour it).
I remember previous debate on getting a guaranteed UTC timestamp, and
this might be a useful way forwards provided obviously that the
underlying OS plays ball.
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
More information about the fpc-devel