[HN Gopher] 2020 Leap Day Bugs
___________________________________________________________________
2020 Leap Day Bugs
Author : mj1586
Score : 145 points
Date : 2020-02-29 18:28 UTC (4 hours ago)
(HTM) web link (codeofmatt.com)
(TXT) w3m dump (codeofmatt.com)
| xxpor wrote:
| 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.
| indecisive_user wrote:
| Interesting observation.
|
| I played around with it a little on google maps. It says it
| pulls route information directly from the King County transit
| website[1] which lists routes by the day of the week, not by
| the date, and seems to be displaying the routes for today just
| fine. My guess is that it's a Google issue, but maybe the King
| County transit website was broken earlier today and gmaps is
| just serving the cached routes now.
|
| For anyone curious, this is what it currently looks like to get
| from Bellevue to Redmond in google maps.
| https://i.imgur.com/wMTIzBL.png
|
| [1]https://kingcounty.gov/depts/transportation/metro/schedules-
| ...
| user982 wrote:
| A line in one of my Python daemons has been crashing it
| repeatedly all day: 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
|
| It's not mission-critical, so I'm just going to wait it out until
| tomorrow.
|
| EDIT: Hacked it out. isotime =
| datetime.strptime(f"{time.get('title')} {YEAR}
| {tzoffset:+03d}00", '%a %d %b %I:%M:%S %p %Y %z').isoformat()
| 1wd wrote:
| https://bugs.python.org/issue26460
| phoobahr wrote:
| That strap time parsing doesn't fail under python 2.7.17 or
| 3.8.1
| user982 wrote:
| Python 2.7.17 (default, Dec 31 2019, 23:59:25) Type
| "help", "copyright", "credits" or "license" for more
| information. >>> from datetime import datetime
| >>> datetime.strptime('Sat 29 Feb 12:00:00 PM', '%a %d %b
| %I:%M:%S %p') Traceback (most recent call last):
| File "<stdin>", line 1, in <module> ValueError: day is
| out of range for month
| park_94110 wrote:
| This is because 1900 is the default year in datetime. 1900
| was not a leap year.
| user982 wrote:
| I know, I'm just providing a counterexample to phoobahr.
| detaro wrote:
| Interesting. Given the documentation of strptime, I would have
| expected that to not be possible at all (since constructing a
| datetime without a year isn't possible directly)
| JensenDied wrote:
| 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.
|
| 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.
| Yessing wrote:
| is there something special about 2020 (regarding leap years)?
|
| the rule I know is divisible by 4 && ( not divisible by 100 ||
| divisible by 400) so 2020 is not even an edge case.
| rachelbythebay wrote:
| Let's not forget the stuff that'll break December 31, 2020...
| because it'll be day 366 (or 365, if 0-indexed).
|
| Anyone still using a Zune out there?
| ddevault wrote:
| Here's mine:
|
| https://git.sr.ht/~sircmpwn/meta.sr.ht/commit/e0be9dcd8e96f9...
| progval wrote:
| I was about to ask why you didn't use a timedelta, and then
| found out that datetime.timedelta doesn't support anything
| greater than week.
|
| It also has this incorrect example:
| https://docs.python.org/3/library/datetime.html#examples-of-...
| kgabbott wrote:
| I respect wanting or needing to do this with just the builtin
| datetime module. For everyone else, I recommend relativedelta
| from the dateutil package:
| https://dateutil.readthedocs.io/en/stable/relativedelta.html
|
| e.g.: >>> from dateutil.relativedelta import
| relativedelta >>> date = datetime.utcnow().date()
| >>> date datetime.date(2020, 2, 29) >>> date +
| relativedelta(years=1) datetime.date(2021, 2, 28)
| mj1586 wrote:
| I added to here: https://stackoverflow.com/a/60468711/634824
|
| Thanks.
| imperialdrive wrote:
| The bulk of our deployed Yealink T56 phones displayed February
| calendar events for the wrong day. I never did find out why.
| pm215 wrote:
| I hear this is a firmware bug, and should automatically sort
| itself out once we hit March (but there is a bugfixed f/w due
| too). My pet theory/guess was that there was a
| misimplementation of some algorithm like Zeller's congruence
| (https://en.m.wikipedia.org/wiki/Zeller%27s_congruence) for
| calculating the day of the week, which works on an adjusted
| year starting in March, because I couldn't come up with any
| other reason why a leap year bug would manifest for all days
| before feb 29 and then not thereafter. But there is probably a
| duller explanation :-)
| sproketboy wrote:
| M$ loser shill.
| btmiller wrote:
| 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?
| est31 wrote:
| Just solve it the Google way: https://xkcd.com/2266/
| andreygrehov wrote:
| So happy to see Timehop in this list. I was a little worried
| about releasing not-a-bug-but-a-feature, but it played out great
| :)
| mj1586 wrote:
| I love the image, BTW! :)
| geforce wrote:
| My car clock went back from 2:00AM to 12:00. I was really
| wondering what happened.
| tech234a wrote:
| My Timex Expedition watch also skipped to March 1.
| makomk wrote:
| That's fairly normal for older or more basic digital watches -
| they don't know anything about the year, so every four years
| you have to manually set them back the 29th of February. I
| think that people see this as a bug says something about
| changing expectations. Pre-digital watches generally didn't
| know about months either, so required manual date adjustment
| every other month. The framing of this manual adjustment as a
| bug feels like it comes from our experience of dealing with
| computer software all the time.
| schoen wrote:
| Or from dealing with more recent digital watches that do know
| about the year.
| anonsivalley652 wrote:
| Stupid Q:
|
| 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)?
|
| https://mailarchive.ietf.org/arch/msg/syslog/DDLgKsRPITFXYSB...
|
| http://www.madore.org/~david/computers/unix-leap-seconds.htm...
|
| https://tools.ietf.org/html/rfc5424
|
| https://cr.yp.to/libtai/tai64.html
|
| https://cr.yp.to/libtai.html
| wtallis wrote:
| Is there a real need for syslog to handle leap seconds? As that
| email you linked to points out, most implementations are likely
| to screw it up to some extent; requiring everyone to ignore
| leap seconds seems to narrow the range of possible behaviors.
| It also strikes me that syslog timestamps aren't something you
| should be depending on too heavily in the first place,
| especially not for things like calculating precise time
| durations between separate messages.
| anonsivalley652 wrote:
| Two wrongs don't make a right, but three lefts do.
|
| Throwing shade without evidence doesn't demonstrate
| professionalism, it demonstrates laziness.
|
| Correlation on high-volume production systems requires
| precise timestamps _all the time._
| burpsnard wrote:
| it's bad enough guessing dmy or mdy, without wondering if we
| earned interest on that 10 billion euros that appears to have
| spent an entire second in a transit account earning 2.7% per
| annum (legal think 'annum' implicitly includes the
| leapsecond, an assurance resting on dozens of assumptions and
| misunderstandings of many ibscure treaties and standards and
| policies, modulo the case law in jurisdictions where
| precedents can redefine)
| dictum wrote:
| Random thought: we're now closer to 2038 than to Y2K.
| tempay wrote:
| It's already here...I saw an issue a few weeks ago a bunch of
| production systems failed upon seeing a certificate signed by a
| CA root that expires after 2038.
| martin-adams wrote:
| and only heading in that direction
| gumby wrote:
| Speak for yourself.
| ge96 wrote:
| what does this mean? you're okay if you're using 64bits? just
| briefly skimmed the 2038 wikipedia page, mentioned 32bit
| onei wrote:
| If you store time as seconds since the Unix epoch (1st Jan
| 1970), you'll overflow a 32 bit unsigned integer in 2038
| (around March iirc) and time will suddenly be back in 1970
| again. I believe the Linux kernel did some work to circumvent
| this on 32 bit systems in a recent release, but if you're
| running an old 32 bit system you're probably out of luck.
| FreeFull wrote:
| Actually, it's signed 32-bit integers that overflow in
| 2038. Signed integers have been used because people wanted
| to store dates earlier than 1970 too.
| adrianmonk wrote:
| And probably because signed integers are a default choice
| in certain languages and/or maybe on certain
| architectures.
|
| Java, for example, famously doesn't even have an unsigned
| 32-bit integer primitive type. (But it has library
| functions you can use to treat signed integers as
| unsigned.) Ultimately not a good design choice, but the
| fact that it actually wasn't _that_ limiting and
| relatively few people care or notice tells you that many
| people have a mindset where they use signed integers
| unless there 's a great reason to do something different.
|
| Aside from just mindset and inertia, if your language
| doesn't support it well, it can be error-prone to use
| unsigned integers. In C, you can freely assign from an
| int to an unsigned int variable, with no warnings. And
| you can do a printf() with "%d" instead of "%u" by
| mistake. And I'm fairly sure that converting an out of
| range unsigned int to an int results in random-ish
| (implementation-defined) behavior, so if you accidentally
| declare a function parameter as int instead of unsigned
| int, thereby accidentally doing an unsigned to signed and
| back to unsigned conversion, you could corrupt certain
| values without any compiler warning.
| klingonopera wrote:
| > _out of range unsigned int_
|
| AFAIK, that doesn't exist? Otherwise, unsigned would also
| have UB?
| klingonopera wrote:
| One of the biggest mistakes in IT ever, in my opinion.
|
| I'd even go so far to say that defaulting to signed
| instead of unsigned was also one of the biggest blunders
| ever. I would've never defaulted to a type that
| inherently poses the risk of UB if I have another type
| that doesn't.
|
| Though it's also possible that precisely that was the
| reasoning for it.
|
| Some more thoughts on unsigned vs. signed:
| https://blog.robertelder.org/signed-or-unsigned/
| function_seven wrote:
| Or: We're now in the equivalent of 1982. Plenty of time to
| worry about it later!
| hmate9 wrote:
| This is why no one should ever ever write their own Time or Date
| library. The number of edge cases is simply enormous
| velox_io wrote:
| Ask Jon Skeet: https://blog.nodatime.org/2011/08/what-wrong-
| with-datetime-a...
| hyperpape wrote:
| When you encounter someone saying "no one should ever", you
| can substitute "fewer than a half dozen groups of people
| should tackle this problem (in systems they want to use in
| production). It will take each such group a tremendous number
| of hours, involving a multi-year process of slowly finding
| edge cases and missing functionality."
|
| If that's not true, then there's room to complain, but dates
| and times fit the bill. In some ways they're worse than other
| "harder" problems, because people are more likely to think
| those harder problems are too hard for them. And while the
| vast majority of companies don't need a proprietary database,
| it's more likely to be a competitive advantage than your own
| datetime library.
|
| I think I _could_ eventually write a good datetime library.
| But I certainly should not, unless I decide that 's going to
| be one of my major efforts to help a language that doesn't
| already have one.
| maxerickson wrote:
| What if people tried to speak precisely for effect instead
| of hyperbolically for emphasis?
| jrandm wrote:
| I believe accurately conveying identical information in a
| manner everyone can understand is an impossible, or at
| least unreasonable, burden to place on individuals.
|
| Instead, what if people tried to hear graciously and
| "assume good faith"?
|
| The quote is ripped from HN's guidelines.
| maxerickson wrote:
| Can you please explain more about how your response
| relates to my comment?
|
| For instance, I've not placed the burden of "conveying
| identical information in a manner everyone can
| understand" on anyone, nor have I assumed bad faith. So
| it seems like a weird comment to tack onto mine, but I am
| assuming I just don't correctly understand.
| IggleSniggle wrote:
| Hyperbole and precision can get tricky in human language
| because different cultural groups have different language
| encodings for the same sets of words.
|
| For example, if you live in London then "9 in the
| morning" means when the world synchronized clocks agree
| that, locally for you, the time is 9am. But if you say "9
| in the morning" to someone in Belize, it means "first
| thing after you are finished with your morning and ready
| to start your day," which can mean 1pm in some cases.
|
| Here's a lovely article on these kind of time-keeping
| differences, around something that you might expect to
| have a precise meaning:
|
| https://www.businessinsider.com/how-different-cultures-
| under...
|
| More to the point at hand, however, you suggested that
| people not speak in hyperbole but instead speak
| accurately. Although you can request that others adjust
| their use of language while in your presence to better
| meet your needs for a certain kind of precision, policing
| other people's language isn't possible. However, re-
| interpreting what people say into what they mean is
| somewhat possible for an astute listener who understands
| the context.
| maxerickson wrote:
| You are making my simple statement really complicated.
|
| I'm not walking around demanding people change their
| communication to accommodate me, I'm suggesting that
| trying to speak precisely can be a useful exercise.
| IggleSniggle wrote:
| I assumed you were being precise when you asked "why
| can't people speak more precisely" and also when you
| asked "can you explain how your comment relates to mine?"
|
| I am not the person you originally responded to, fwiw,
| and I agree that trying to speak precisely is a useful
| exercise, even if I believe it is impossible except in
| highly formalized languages.
| maxerickson wrote:
| I wrote "What if people tried to speak precisely", not
| "why can't people speak more precisely".
| Misdicorl wrote:
| Almost all the edge cases with time have to do with
| localization.
|
| Build your time library on (un)signed 64 bit integers
| representing the number of nanoseconds since the utc epoch.
| Adjust above sentence to reflect the level of precision and
| range your use case needs. You are now done for 80% of use
| cases (perf timing, logging, timeouts, event storage, event
| ordering within jitter).
|
| If you need to parse/display for humans or have something
| happen at a particular time in a particular timezone, things
| get gross. But that's no different than any other situation
| where you eventually have to interface machine data with
| humans. Either it's your particular expertise or it's a
| distraction and you should use someone else's solution.
| mytailorisrich wrote:
| I've come to the same conclusion as you: Keep time as a
| purely monotonic integer for everything and convert that as
| needed to display to humans.
|
| This also pushes all the madness to the edges and out of the
| business logic.
|
| That being said, this works well for applications that are
| not "date intensive" so to speak. If your business logic has
| to deal specifically with calendar dates, e.g., monthly
| events, then you have to deal with calendar months and all
| that this involves, including explicitly dealing with the
| 29th February.
| nradov wrote:
| The monotonic integer approach doesn't work for most
| healthcare applications. Due to safety and compliance
| requirements we typically need to record both the local
| time and the zone offset which applied at that instant.
| ken wrote:
| Your percentages are backwards, IME. Timeouts and logging and
| such are definitely not "80% of use cases". Interfacing with
| humans and human systems are.
| Misdicorl wrote:
| I disagree. Time is pervasive and will exist in every
| application in some way. It will only matter to the user in
| a small subset of them
| ajnin wrote:
| You're assuming a source of monotonic nanotime is easy to get
| and will always be available. This is not the case. As far as
| I know you have either "wall time" as usually defined, with
| all the problems associated with clock drift, NTP syncs,
| computer going into sleep mode, etc, or "nanotime" which is
| some time delta from some arbitrary reference and which can
| only be used to compute time differences and not arbitrary
| instants in time. One can not be converted into the other
| easily, or at all.
| burfog wrote:
| You can still have problems.
|
| It may be determined that the computer's clock got too far
| ahead. For example, it booted and you cared about time, but
| NTP hadn't yet made corrections. Suddenly the time runs
| backwards.
|
| Leap seconds may get interesting too, especially if you have
| to predict ahead or if the OS isn't updated often enough.
| (there is a 6-month warning) If you want to call leap seconds
| an issue for humans, then you aren't using UTC at all. You're
| using TAI. Software interfaces often ignore the distinction
| between UTC and TAI, and even between UTC and UT1, preferring
| to pretend these issues don't exist. POSIX is in conflict
| with international timekeeping, effectively requiring that
| there are zero leap seconds.
| codetrotter wrote:
| > Suddenly the time runs backwards
|
| It is my understanding that the way NTP deamons work is
| that time is never adjusted backward. Instead, the ticks
| are "slowed down" on the local machine until it is in sync
| with the NTP time. However, if the difference is too great
| then I think NTP deamons might refuse to correct the time
| all together. So then, if my understanding is correct, your
| machine is "stuck in the future". But it will never make a
| jump backwards because of NTP.
|
| However, I am not familiar with the intricate details of
| NTP so do take this with a grain of salt.
| twic wrote:
| My understanding (i am also not an expert!) is that
| common NTP implementations will do the slowing down
| ("slewing") to correct small errors, but will just change
| the time ("stepping") to correct large errors. It will
| even do this if that means time going backwards.
|
| Subject to configuration, of course. man ntpd [1] says:
|
| > Sometimes, in particular when ntpd is first started,
| the error might exceed 128 ms. This may on occasion cause
| the clock to be set backwards if the local clock time is
| more than 128 s in the future relative to the server. In
| some applications, this behavior may be unacceptable. If
| the -x option is included on the command line, the clock
| will never be stepped and only slew corrections will be
| used.
|
| [1] https://linux.die.net/man/8/ntpd
| Misdicorl wrote:
| Leap seconds are only a problem for wall clocks
| (localization) and deciding whether to call something utc
| or tai.
|
| The ntp case is contrived. Either you care and wait until
| ntp has connected to do your stuff. Or you care and don't
| let ntp rewind and instead smear. Or you don't care and
| deal with the consequences.
| ehsankia wrote:
| It's not only about writing your own library though. For
| example, it's often not reading the documentation properly.
|
| In Python, if you take a datetime, and call .replace(year=X) on
| a datetime for Feb29, it'll throw a ValueError.
| Aeolun wrote:
| Even if you replace it with another leap year?
| 76543210 wrote:
| How about C rtos? How should that be handled?
___________________________________________________________________
(page generated 2020-02-29 23:00 UTC)