[toasty@dragondata.com: Re: Leap second reminder]

[Colm MacCarthaigh <co...@stdlib.net>]

This may or may not be a registered "bug", but thought I'd forward it;

----- Forwarded message from Kevin Day <to...@dragondata.com> -----

From: Kevin Day <to...@dragondata.com>
Date: Sat, 31 Dec 2005 13:32:20 -0600
To: nanog@nanog.org
Subject: Re: Leap second reminder


On Dec 31, 2005, at 11:58 AM, Kevin Day wrote:

>
>
>Just a reminder, at midnight UTC there's a leap second added to  
>most time systems.
>
>


I've had quite a few replies already off list, that I'll sum up:

1) ISO 8601 specifically defines ":60" as a valid representation for  
seconds, just for this event.  If your app breaks, it's probably not  
obeying the relevant RFC.

2) Anything using the obvious implementation of regular expressions  
to check for a valid time is probably going to fail "23:59:60",  
leading to events not being logged,  or transient weirdness for that  
second.

One example I thought of after a few minutes is SpamAssassin, who  
will flag a mail header:

Date: Sat, 31 Dec 2005 23:59:60 +0000

As "INVALID_DATE", bumping up its spam score by 1.7 to 2.0(by  
default), because of the regexp it uses which contains "[0-5][0-9]"

3) Two people have noted that their Juniper routers spat out some  
strange ntpd messages earlier today, such as:

Dec 31 06:26:46 hostname xntpd[66479]: time reset 0.999681 s
Dec 31 06:48:11 hostname xntpd[66479]: time reset -0.437785 s
(local time set to America/Chicago)

4) You can't set your clock to 23:59:60 manually, which makes testing  
what's going to happen difficult.

5) The "leap second pending" bit that's supposed to have been set by  
now in NTP isn't being set by some clock sources, leading some to  
wonder what they're planning on doing at midnight.




----- End forwarded message -----

-- 
Colm MacCárthaigh                        Public Key: colm+pgp@stdlib.net

Re: [toasty@dragondata.com: Re: Leap second reminder]

[Theo Van Dinter <fe...@apache.org>]

On Sat, Dec 31, 2005 at 07:53:51PM +0000, Colm MacCarthaigh wrote:
> 1) ISO 8601 specifically defines ":60" as a valid representation for  
> seconds, just for this event.  If your app breaks, it's probably not  
> obeying the relevant RFC.
> 
> 2) Anything using the obvious implementation of regular expressions  
> to check for a valid time is probably going to fail "23:59:60",  
> leading to events not being logged,  or transient weirdness for that  
> second.
> 
> One example I thought of after a few minutes is SpamAssassin, who  
> will flag a mail header:
> 
> Date: Sat, 31 Dec 2005 23:59:60 +0000
> 
> As "INVALID_DATE", bumping up its spam score by 1.7 to 2.0(by  
> default), because of the regexp it uses which contains "[0-5][0-9]"

Hrm.  Well, in looking at my corpus, I have 0 hits for "60" in the seconds
place, and only 5 spam hits for "60" in the minutes place.  So I'd say
we could add in "60" as a valid number of seconds and not have any issue.  On
the flip side, I don't think this is a very serious issue since there were no
hits on ham at all -- but we should be correct in behaviour.

I'm putting in a new version in my sandbox (along with a new more "strict"
version) which accepts 60 as valid for seconds, along with a test to make sure
it's allowed.

-- 
Randomly Generated Tagline:
"Where's the ladies' sty?  I desperately need to powder my snout."
                                        - Wally's Elbonian Mail-Order Bride