[tz] Leap year bugs

[Brian Inglis]

On 2020-01-22 11:37, Paul.Koning at dell.com wrote:
>> On Jan 22, 2020, at 1:32 PM, Matt Johnson-Pint wrote:
>> Hello Time People!  Apologies in advance, as I know this is a bit off-topic being not about time zones, but I know that many of you are invested in date and time programming, and I'd appreciate some peer discussion.
>> ...
>> My question for the community is this:  Why are Y2K and Y2038 bugs such a hot topic when they are/were one-time events, but yet leap year bugs are rarely discussed even though they are recurring and can have critical impact?  People seem to remember 20 years ago, but not 4 or 8 years back.  Why?
>>
>> Are any of you working on leap year related issues?  Have you checked your date math for leap year bugs? If not, why?
> 
> My guess is that getting leap years right is a simple matter that any competent programmer will understand, while Y2K and Y2038 are not so obvious.
> 
> As you said, these others are once in a lifetime issues.  It's precisely that point that makes them less understood.  Leap years have been encounteredin software for half a century or more; it is to be expected that people know how to get this right.  
> 
> It wouldn't surprise me to see software that falsely claims 2100 is a leap year, though.  Fortunately we have a while to deal with those bugs.

It's apparently a lot worse than we think.
Many systems do not accept February 29 at all.
People born on that date have continuing problems, including scepticism that
anyone is born on that date:

https://globalnews.ca/news/2539442/the-hassles-of-being-a-leap-year-baby/

[really hassles of being born on the leap day!]

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.