Let's not forget the stuff that'll break December 31, 2020... because it'll be day 366 (or 365, if 0-indexed).<p>Anyone still using a Zune out there?
Sears appears to have have taken this to a new level. I got two emails from them today. The first arrived at 6:36 AM, with subject<p>> Confirmed! Your mystery Leap Year offer awaits inside. How much will you save?<p>The second arrived at 9:54 AM, with subject<p>> Oops! Your code is fixed. (We shoulda looked before we leap-yeared...)<p>The messages themselves appear to be identical except for some query parameters on some URLs, so I'm guessing that whatever they botched for leap year was on the server when one tried to respond to the offer.<p>Botching Feb 29 in general date handling code is embarrassing, but there is it least a somewhat plausible excuse that you just forgot about that special case. But botching Feb 29 in code that is meant to only work on Feb 29? Wow.
I haven't been able to figure out if this is a Google issue or King County Metro issue yet, but google maps transit directions are completely broken today. Every suggestion is "take Lyft" or wait until 4 am tomorrow.
I ran into this already on January first. Someone in the last 4 years changed/created a function in a MUD that I now maintain, to convert Unix timestamps into iso8601 strings for MySQL.<p>They did the math for which year is a leap year incorrectly, which wasn't the bug that bit us, they helpfully added the leap day regardless of where in the year it was. The tests they wrote targeted the middle of the year and missed it. I just pulled in date2j and related match from postgres, added more test cases.
A line in one of my Python daemons has been crashing it repeatedly all day:<p><pre><code> isotime = datetime.strptime(time.get('title'), '%a %d %b %I:%M:%S %p').replace(year=YEAR, tzinfo=TZ).isoformat()
ValueError: day is out of range for month
</code></pre>
It's not mission-critical, so I'm just going to wait it out until tomorrow.<p>EDIT: Hacked it out.<p><pre><code> isotime = datetime.strptime(f"{time.get('title')} {YEAR} {tzoffset:+03d}00", '%a %d %b %I:%M:%S %p %Y %z').isoformat()</code></pre>
LinkedIn has one! Yesterday it listed my time with my current employer as 2 years and 9 months. Today, it’s 2 years and 8 months! Can anyone venture a guess on how I time traveled?
So frustrating that my embedded code works without a hitch and our company is nearly bankrupt, while our bank with billions of dollars in annual profit goes offline since it cant handle leap years.
huh! i just noticed few hours ago a pi i use has had the wrong date which was set to a day earlier. I quickly determined a faulty ntp server i had hard configured was giving the bogus time. In case it is of interest its address was "144.76.60.190" and was chosen by random chance because i cant resolve names without working time on that machine (don't ask). It appears to be taken offline by now though but i checked its giving the wrong time before changing to another server.<p>Also, but probably unrelated, my WiFi stopped working exactly 00:00AM CET but that might be unrelated as it does that all the time :)
is there something special about 2020 (regarding leap years)?<p>the rule I know is divisible by 4 && ( not divisible by 100 || divisible by 400) so 2020 is not even an edge case.
I'm kinda surprized that date libraries break with a simple leap year like 2020. I'd have more understanding if it happened with the year 2000(leap year) or 2100(not a leap year), but the basic "is year divisible by 4" check should be good enough until 2100.
relevant: falsehoods programmers believe about time <a href="https://news.ycombinator.com/item?id=4128208" rel="nofollow">https://news.ycombinator.com/item?id=4128208</a>
I deposited a cheque using the ScotiaBank mobile app on March 1, and when I looked at it on my online banking page, it said that it was deposited on March 2!<p>Seems hard to believe that a mobile app would be allowed to tell the server what time the cheque was deposited!
Stupid Q:<p>Why doesn't the syslog protocol (RFC5424) deal with leap seconds (the seconds field goes to 00-59, not 00-60)? Are they using UTC (they would have to ignore LS and have crappier logs) or TAI (doesn't have LS)?<p><a href="https://mailarchive.ietf.org/arch/msg/syslog/DDLgKsRPITFXYSBzicpbqTwtbk8/" rel="nofollow">https://mailarchive.ietf.org/arch/msg/syslog/DDLgKsRPITFXYSB...</a><p><a href="http://www.madore.org/~david/computers/unix-leap-seconds.html" rel="nofollow">http://www.madore.org/~david/computers/unix-leap-seconds.htm...</a><p><a href="https://tools.ietf.org/html/rfc5424" rel="nofollow">https://tools.ietf.org/html/rfc5424</a><p><a href="https://cr.yp.to/libtai/tai64.html" rel="nofollow">https://cr.yp.to/libtai/tai64.html</a><p><a href="https://cr.yp.to/libtai.html" rel="nofollow">https://cr.yp.to/libtai.html</a>
I think I found one. My Amex bill is due on the 29th and I have a direct debit to pay it automatically. However it never got taken. First time this has ever happened.<p>Let's see if it happens today since it's now the 1st.
Considering billions of devices and services not being affected, these bugs are very insignificant. At least we figured out leap day bugs and not having y2k crisis' every four years.
I learnt the following test for leap year early in my software engineering career from the book "The C Programming Language" by Kernighan & Ritchie (see section 2.5 Arithmetic Operators):<p><pre><code> (year % 4 == 0 && year % 100 != 0) || year % 400 == 0
</code></pre>
The following test also works:<p><pre><code> year % 4 == 0 && (year % 100 != 0 || year % 400 == 0)</code></pre>