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@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. -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
