• WTFGuy (unregistered)

    Ref Remy's "The real WTF is that, somehow, this code worked at one time."

    Said another way, the real WTF is that some version of mySql was silently converting datetimes like <2019-01-23T24:01:01> to be interpretted as <2019-01-24T00:01:01>.

    Which is, as we all know, is the frist second of the frist minute of the frist hour of today. OBOB my butt! Fence posts!? I don't see no steenkin' fence posts!

  • Your Name (unregistered)

    At the same time, they earn approximately 4.17% more profit, and any operation they perform takes 4% less time (in relation to the duration of the day) compared to those poor people living in 24-hours-long-day world. If this is not an effective optimization, then I don't know what is...

  • (nodebb)

    We all want 25 hours in a day. These guys made it possible. If you dare, you can turn a want into a have.

  • my name is missing (unregistered)

    I knew my days seemed much longer than they should.

  • Aspie (unregistered)

    Older versions of MySQL used to accept daft dates and times. I once committed a copy/paste error and inserted 31-Feb into a datetime column. It "helpfully" didn't throw an error and changed it to the 3rd of March.

  • (nodebb) in reply to Aspie

    Yeah, that sounds like MySQL. Terrible, terrible system. At least it's improved a bit.

  • Little Bobby Tables (unregistered)

    So TRWTF is

    a) MySQL suddenly breaking colossal quantities of applications which used to "work" and now crash?

    or:

    b) an off-by-one error not referred to as an OBOE, thereby making it impossible for someone who makes such a mistake counting, er, pink things, to be described as having committed a "pink OBOE"?

    Which is it?

  • MIKE (unregistered)

    I still prefer the beatles with their eight days in a week.

  • Vilx- (unregistered)

    I'd shorten it to "OBOBO". Just... seems more appropriate.

  • Chronomium (unregistered)

    Better check the rest of this guy's code for instances where he assumes arrays start at 1.

  • Not Sir Paul (unregistered)

    This code should work eight days a week.

  • Cidolfas (unregistered)

    Most likely a change in the "strict" default setting, which seems to change depending on your MySQL version.

  • (nodebb)

    PHP and MySQL strike again!

  • Anonymous') OR 1=1; DROP TABLE wtf; -- (unregistered)

    They're just future-proofing the code. Once the Earth's rotation slows down enough in a few eons, the IERS will start inserting leap hours when needed, rather than those puny leap seconds we see nowadays.

  • (nodebb) in reply to Anonymous') OR 1=1; DROP TABLE wtf; --

    You may jest, but I fear the IERS will simply "roll the hour back" same as is done when switching from DST to Standard Time.
    I think we just need to redefine the ISO unit of time (second) so that we run thru 25*3600 = 9E4 seconds per day.

  • (nodebb)

    Centaurian time, standard 37-hour day. Give it a few months. You'll get used to it. Or you'll have a psychotic episode.

  • eric bloedow (unregistered)

    reminds me of a story where someone messed up the dates and made the first day of every month a ZERO!

  • Alex Papadumbass (unregistered)

    There's an off by one error in your brain as well. 25/24 is not 104%, 26/25 is. Glass house, meet stones. Bonus stone for garden path sentence.

  • BobE (unregistered)

    So. . .in the past a "Cust"omer_"update"_"enddate" occurred in 24 hours 59 minutes and 59 seconds from now. . .enough time for a human to scan the rest of the entered data fields and do something. . .but with the new version of MySQL there is no longer a tomorrow.

    While the existing code is perhaps not the best way to specify a future date, I'll wager this functionality was a known MySQL thing that many developers took advantage of to avoid one of those hard date related calculations.

    For a tongue in cheek viewpoint: In the past you received 72 hours to pay that parking ticket, but Acme Traffic Ticketing does not want to rewrite their entire code base for this MySQL update so now you have just 24:59 to pay that ticket, or receive additional fines.

    ♪♫♪ Tomorrow, tomorrow, You're always a day awayyyyyy

  • DCL (unregistered) in reply to Chronomium

    Depends on the language you're using.

  • a commentator (unregistered)

    My guess is the code only worked on Mondays.

  • snoofle (unregistered) in reply to Aspie

    ...except for leap years

  • (nodebb)

    Could have been avoided if the convention of using half-open intervals to represent absolute time intervals were used (any given timestamp represents a period of time that starts at the instant indicated). Then something that starts at 2019-06-07 00:00:00.000 and runs for three days is indicated by adding ending at 2019-07-09 00:00:00.000 and not 2019-07-08 24:59:59.999.

  • Mark (unregistered) in reply to Watson

    I had hoped that was already the case, but have been dismayed by the increasing use of 12:01am and 11:59pm as start and end times for events that last for '24 hours'.

  • Olivier (unregistered) in reply to WTFGuy

    It is not uncommon, in Japan, to see that a mall will be open until 26:00, meaning 02:00 the next day.

  • snofle (unregistered)

    so, developer went and upgraded the entire f***g OS and then bad st happened. man, didn't see that coming.

  • Anon (unregistered)

    That's not a bug. Days should start at 6:00:00 and end at 29:59:59. The real WTF is incrementing the date when most people are awake.

  • jgh (unregistered) in reply to Watson

    I've looked at that many times, and I'm still sure that's only two days.

    And yeah, it was a bit odd in Japan seeing 'Road closed: 21:00 - 28:00'

  • Paul (unregistered)

    A pedant writes: if you're in a country that observes DST then on the two changeover days per year, one day will be 23 hours long, the other 25, though 24:59:59 will always be an invalid time.

  • LearnToRound (unregistered) in reply to Alex Papadumbass

    25/24=1.041(6) => 1.04 to 2 d.p.

Leave a comment on “Giving 104%”

Log In or post as a guest

Replying to comment #:

« Return to Article