what on earth is firefox up to?

Tim ignored_mailbox at yahoo.com.au
Sun Jul 1 14:20:05 UTC 2012


On Sun, 2012-07-01 at 08:47 -0400, Tom Horsley wrote:
> I don't understand the complicated interactions that
> make a leap second confuse a computer more than the
> RTC running slow confuses it,

It's a smallish problem to tell the computer that the time is wrong, and
to reset the clock to another time, whether forwards or backwards.
Sometimes that's handled without major issues, sometimes it does have
repercussions.  But it's something that computing has dealt with for
quite a long time.

Leap seconds, on the other hand, means that for one particular moment in
time, a minute isn't 60 seconds long.  That's not an event that a lot of
people calculating dates and times have ever considered, and some things
handle that very badly, such as crashing.

For some situations, you can simply reset and start again, after the
time change.  But how do you handle things that happen during that extra
second with software that has no concept of a 61 second minute?  When
something happened on that date, how do you represent it if you cannot
say a date of 2012-06-30 00:00'60"?  (Remember the seconds count from
zero to 59, not 1 to 60.)  Do you call it 00:01'00" and have two,
different, 1 minutes past midnight?

And then there's the converse...  If we have a year where they have to
deduct seconds, how do represent something that happened during the,
now, removed seconds, but recorded by the, then, still counting clock?

And, in either case, when you use a system that counts the number of
seconds since a certain epoch, to show you the date and time of
something, do you show the right time and date when there's a miscount
in the middle of it?  You need a correction table of dates it has to
modify, and I don't think anybody's ever produced a clock program that
does that.

On that note, I've often wondered how systems that look at a file's GMT
datestamp and tell you that time translated into your local time, cope
with datestamps from a long way away, when timezone rules keep on
changing.  We could maintain a table of rules so that the computer can
correctly give you the times during summer of 1976, but how far back is
the table maintained?  Sure, you won't have to read back a timestamp
from the year 1827, but there could be a reason to calculate something
from a known date and time, that's not to do with a computer file.  And
there's the converse function.  If you had to calculate a date and time
in 2023, would you know what rules would be applied during that year to
do it correctly?

-- 
[tim at localhost ~]$ uname -r
2.6.27.25-78.2.56.fc9.i686

Don't send private replies to my address, the mailbox is ignored.  I
read messages from the public lists.





More information about the users mailing list