= Сообщение: 2291 из 7124 ====================================== FTSC_PUBLIC = От : Michiel van der Vlist 2:280/5555 30 Jan 17 12:30:54 Кому : Nicholas Boel 30 Jan 17 12:30:54 Тема : FSP-1040.001 Draft #3 FGHI : area://FTSC_PUBLIC?msgid=2:280/5555+588f2ee5 На : area://FTSC_PUBLIC?msgid=1:154/10+588e7c9a = Кодировка сообщения определена как: CP850 ================================== ============================================================================== Hello Nicholas,
On Sunday January 29 2017 17:34, you wrote to me:
NB> That only leaves the leap seconds. Do we want to account for that for NB> the future? Or leave it as is (currently not in use)?
I say it is a non-issue.
For starters: my educated guess is that the original author never had leap seconds in mind when he declared a range of 00-60 for the seconds. I think that simply was an error. The reason I think that is that he made the same error for the minutes and the hours and there certainly are no leap seconds and leap hours. So why don't you ask him?
Having said that: In the history of Fidonet there have been a grand total of 15 leap seconds. I very much doubt even a single message with "60" in the seconds field has ever been sent out into the network. It requires a lot of imagination to call that "current practise".
Allowing "60" for the seconds is a can of worms that we should not open. Yes, "60" is a possible value for the UTC clock in the rare event of a leap second. But I have yet to see a domestic clock that can and does actually display it. Most clock - including the clock in my Fidonet PC - will never actually display 60 for the seconds if only for the simple reason that these clocks do not know about leap seconds until after the fact. The seconds will roll over from 59 to 00 and then when a leap second has occurred, they will be one second ahead of the "real" time. A condition that will be corrected some time later. This correction may result in the clock displaying the same second twice in a two second interval.
I also doubt that there is any software in use in Fidonet that will correctly deal with leap seconds. I am pretty certain the routines included in time.h that comes with most C compilers do never return 60 for the seconds. Even in th extreme rare event that Fdionet message was created in the very second of a leap second happening, it still would not display "60" for the seconds. Simple because the clock and the clock routines presentl;y in use in Fidonet dor not return "60".
Should we allow it anyway in order to be prepaired for the future?
I don't think so. It is just not worth the effort. "60" in the seconds (or the minute or the hour) is more likely an error than the result of a leap second. There is a high probability that existing software will barf on it. Weigh that against the benefits. What is the benfit of allowing "60"? The one and only benefit is that it allows the second in the time stamp of a Fidonet message to be correct in the extereme rare event that it is created in the very second that a leap second occurs AND the software being capable of properly dealing with it. And what did we gain? What will be lost if we just say "in the very rare event that a massage is ceated during a leap second just display the seconds as "59" or "00". It will be off by one second at most and who is going to notice or care?
Leap seconds are a can of worms. They cause more problems than they solve. Here is some interesting reading:
Predicting is easy. Making predictions that come true is harder. When the predictions are about the future it is even harder. Nevertheless, I shall make a prediction: The ITU will eventually come to its senses and drop the leap seconds. They will accept the one or two minute per century drift between the atomic time and the mean solar time instead.
