Bug report: https://quality.embarcadero.com/browse/RSP-19329
Bug report: https://quality.embarcadero.com/browse/RSP-19329
Came across some pretty odd behaviour recently, relating to the linker time date stamp. I'm in the UK, and our time is currently GMT. Daylight saving (BST) ended, as it always does, on the final weekend of October. However, DST in the USA ends a week later, the weekend just gone.
This means that last week I was in a zone where DST was not active, but DST applied in the USA.
Why do I think that is relevant? Well, last week the Delphi linker time/date stamped executables with a time that was an hour early. And it was pretty easy for me to be sure of that because GMT happens to have zero offset to UTC, and the time/date stamp is written as UTC.
This week however, the linker time/date stamp is written correctly. I am hypothesising that something in the system is mixing up my locale with USA time zone rules. I find it hard to imagine that the Delphi compiler could get it wrong in this way. It would need to mix the base offset from my locale with the DST offset from a USA locale. I can't imagine how code could be written to do that.
On the other hand, I'm finding it hard to believe that it could be an OS bug.
Even more exciting, I've set my machine's date back a point last week, and now the disparity is two hours instead of one.
This is bending my mind.
Came across some pretty odd behaviour recently, relating to the linker time date stamp. I'm in the UK, and our time is currently GMT. Daylight saving (BST) ended, as it always does, on the final weekend of October. However, DST in the USA ends a week later, the weekend just gone.
This means that last week I was in a zone where DST was not active, but DST applied in the USA.
Why do I think that is relevant? Well, last week the Delphi linker time/date stamped executables with a time that was an hour early. And it was pretty easy for me to be sure of that because GMT happens to have zero offset to UTC, and the time/date stamp is written as UTC.
This week however, the linker time/date stamp is written correctly. I am hypothesising that something in the system is mixing up my locale with USA time zone rules. I find it hard to imagine that the Delphi compiler could get it wrong in this way. It would need to mix the base offset from my locale with the DST offset from a USA locale. I can't imagine how code could be written to do that.
On the other hand, I'm finding it hard to believe that it could be an OS bug.
Even more exciting, I've set my machine's date back a point last week, and now the disparity is two hours instead of one.
This is bending my mind.
David Heffernan yeah, i get that it’s the linker (or the software that displays the build time).
ReplyDeleteI didn’t check what’s actually stored in pe-files that Delphi generates. I just vented my general frustration of having to run into timestamp related bugs that could’ve been prevented easily.
Every time anyone writes code that stores some “local” timestamp, make sure to always store the timezone and DST offset too. Or better yet: consider writing UTC and doing a conversion at presentation time only.
Twice per year, Delphi incorrectly thinks that all my files have changed. Hopefully the linker is a bit smarter with timestamps..
Wouter van Nifterick there's no debate over how to store this timestamp. It's defined by the PE file format. UTC, seconds after the Unix epoch.
ReplyDeleteWhen you consider what just happened, where we "fell back", and thus repeated an hour, there is really no rational alternative to UTC. All else is simply local display.
ReplyDelete