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:

http://www.potaroo.net/ispcol/2016-12/lastsecond.html
http://www.potaroo.net/ispcol/2017-01/leapps.html

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.

Forget about leap seconds in Fidonet.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20130111