• bvs23bkv33 (unregistered)

    TODO: <comment>

  • NULLPTR (unregistered)

    LOL on CocaCola getting NullPointered....

  • The Mole (unregistered)

    If the month starts on a Tuesday then the third Tuesday comes before the third Monday, if they want to wait a bit (26 hours) after the third Monday to apply the patches that is the correct thing to do.

  • (nodebb)

    The <File Description> WTF belongs to whoever built the application that is not responding rather than to Windows itself (unless what failed is part of Windows...). That information comes, classically, from the VERSIONINFO resource in the application, or from other files provided with it, and someone didn't actually put a file description.

  • Frist not frist (unregistered)

    Yelease Yudderick

  • Hellion (unregistered)

    Dashes or not, the SSN should always fail to match because the pattern it's up against is 10 digits long instead of 9....

  • negative infinity (unregistered) in reply to NULLPTR

    Happy birthday, nullptr!

    Even CocaCola rememers your birthday!

    Tell me, did you invite undefined and NaN to the party?

  • Zayn (unregistered)

    The Real WTF is getting birthday wishes from Coca-Cola.

  • (nodebb)

    Social Security Numbers also only have 2 digits between the dashes.

  • (nodebb)

    @The Mole Right. Another way to describe it would be 02:00 Tuesday after the third Monday.

  • (nodebb) in reply to Barry Margolin 0

    I have never seen a scheduled task system allow tasks to be scheduled that way. Though to be fair, I've also never seen a scheduled task accept "26 hours after the third Tuesday", either.

    (My day-after-patch-Tuesday crontab is "0 4 9-15 * wed /path/to/task", personally)

  • (nodebb)

    "No dashes or spaces". Maybe I should use hyphens?

  • Wizofaus (unregistered)

    I've seen 26:00 on car park signs in Japan, and it's discussed here: http://www.city-data.com/forum/asia/2469430-25-00-hour-japan.html, so it's not impossible the software was developed in or for such a region.

  • Zero (unregistered)

    Many izakayas (bars) in Japan have their business hours written like that, for example 18:00 - 27:00. By hand. On a blackboard, with a chalk. No computers.

  • Olivier (unregistered) in reply to Wizofaus

    Yup, I have seen that in Japan too, mall that close at 2am would advertise it at 26:00

  • David Mårtensson (unregistered)

    Some older time reporting systems also use more than 24 hours.

    They where probably not designed to handle night work but due to this they did not limit the hour of day field and since computations assumed all hours are within the same day everything worked out fine :)

    My dad worked at a company using such a system for a few years.

    So the nights shift could be from 18:00 - 26:00 or 6pm to 2am.

    Not a very good way to solve a problem, but in the short run cheaper than replacing it.

  • Technical programmer (unregistered)

    The time values 1:00, 2:00, 3:00 were not used in traditional Japanese timekeeping. The time values counted down from 9 to 4, marked as the length on a joss stick. (Only 6 'hours' in the AM and PM. And they aren't fixed value: night hours are shorter than day hours in the summer, longer in winter).

    Time calculations are best handled by a library... To the relief of computer programmers everywhere, the traditional system was abolished at the restoration.

  • Harris M (unregistered) in reply to Steve_The_Cynic

    Yeah, I've seen this a couple of times with different programs. It will show up in Task Manager too.

  • löchlein deluxe (unregistered)

    Now I have BOFHly thoughts about SodaCompany's "getting too much email?" link.

    (Also, input normalization on dates is perfectly routine, isn't it? Of course, that should work like that, just like "January 33rd, which is Feb 2nd".)

  • The Waffler (unregistered)

    You have to understand... their food was complete and utter crap. But, on the other hand, the waitress... oh my god!

Leave a comment on “Perfunctory Yet Functional”

Log In or post as a guest

Replying to comment #510012:

« Return to Article