• Mario (unregistered) in reply to Mr Fred
    Mr Fred:
    That led to some amusing bugs on Jan 1 2000. For example there were those who did string concatenations instead of addition and got Today is Jan 1 19100.
    The real WTF is that Netscape's javascript did that, and IE's did not.

    (I'ld include an example but I lost the ability to write javascript)

  • (cs) in reply to Theo
    Theo:
    tmountjr:
    Am I missing something in the French back-and-forth that mentions money?
    No they don't mention money, ...
    j'ai des nombre (prix)

    Trans: I have a number (price)

  • Andi (unregistered) in reply to gsmalleus
    gsmalleus:
    my $year = $date[5]+1900;

    This doesn't seem very Y2K friendly.

    But that's the definition of years in perl - $date[5] contains year minus 1900. You can call this a mistake in the perl api, but that's the way it is now.

  • Zygo (unregistered) in reply to Vechni
    Vechni:
    if ($month == 2){ if (($year == 2008)||($year == 2012)){ if ($day < 29){$day++;} else{$day = 1;$month = 3;}

    haha here is a WTF, this code will work until 2016.

    Strictly speaking, it will work after 2016 as well. It just won't work between the hours of 23:59:41 and midnight GMT on February 29th every 4th year afterwards.

    Oh, it will also work every 400th year from 2400 onwards, assuming we're still using the same calendar then.

  • Zygo (unregistered) in reply to Vechni
    Vechni:
    oh we've all done this before when we were new.

    Oi, speak for yourself mate!

    When I was new, I implemented my own gmtime function (well, localtime actually, and no daylight savings support). Unlike the silly ANSI standard, my function returned the correct year, so I never had to add 1900 to anything.

    In my defense, I'd like to point out that to link against gmtime I would have had to shell out $90 or so for a C compiler on my platform.

    My implementation of "19 seconds in the future" (although "20 minutes into the future" would have been more likely in the era when I was young ;-) would have looked pretty much like Yuri's, if Perl had existed at the time.

  • blm (unregistered)

    I thought the real WTF was that the replacement code doesn't do the same thing as the original code.

  • Maks Verver (unregistered) in reply to Nobody
    Nobody:
    That should be: my @time = gmtime(time + 19); -not- my @ time = gmtime(time + 19); No spaces allowed in Perl identifiers!
    Come on, at least test that before you make a fool out of yourself in front of everybody. A space is perfectly fine there. My guess is that the ``@'' is even a separate token from the actual identifier token.
  • (cs)

    I'm also interested in what they did with @date after that.

    Personally, in perl, I pass a date format and the output from localtime/gmtime to POSIX::strftime(), but I bet he formats it manually, too.

  • a robot (unregistered) in reply to tmountjr

    The real WTF is using VB. Oh, wait...

    bob ardkor:
    reminds me of a recent post on a (french, sorry) SEO forum :

    http://www.webrankinfo.com/forums/viewtopic_80454.htm

    for those who don't speak french, the initial poster wants a php function that formats 2500000 to 2,500,000

    the first answer is an interesting home-made function.

    the second answer is, well, the right answer.

    I don't see any code in the second post. O_o

  • Kevin Kofler (unregistered)

    There's another bug you've all missed: the code for December doesn't check the day before incrementing all the way to January 1st!

  • Kevin Kofler (unregistered)

    Oh, and the conversion done to the hours will also break at certain times of the day, as there's no check for the hour exceeding 23.

  • MadCat (unregistered) in reply to gsmalleus

    Oh, but it is. Perl returns the year as the number of years since 1900 -- a reason why in the glorious year 2000, a lot of sites were showing '190100' as the year. Yeah.

    So actually he did get that one right. The rest of it is seriously screwed up.

    Oh, note to submitter ... 'gmtime' is not a library, it's just another function call, just as 'time' is ;)

    Captcha: yummy -- which this perl code definitely is not!

  • Stefan W. (unregistered)

    Well - MS is advising their broken excel-time as a ISO-standard with ms-ooxml (based on 1900 too).

    Q.: How do both solutions handle daylight-saving-times? Perhaps the second solution does?

  • (cs) in reply to n9ds
    n9ds:
    dekarguy:
    Captcha: onomatopoeia (I hope I spell it right)
    You spelled it right, but it still sounds wrong.
    How on earth can "onomatopoeia" sound wrong? Are you a Cretan?
  • anonymous coder (unregistered) in reply to Vechni

    no.

  • (cs) in reply to SomeCoder
    SomeCoder:
    The real WTF is that they hardcoded the 19 seconds...

    In all seriousness... my eyes, the goggles do nothing!!

    The real WTF is that he adds a local time offset (hardcoded) without checking for needing to adjust the date; which he does for the addition of 19 seconds (hardcoded), which is far less likely.

    Actually there are so many real WTFs, I'm not sure I can count them.

  • Aquatoad (unregistered) in reply to Stefan W.
    Stefan W.:
    Well - MS is advising their broken excel-time as a ISO-standard with ms-ooxml (based on 1900 too).

    Q.: How do both solutions handle daylight-saving-times? Perhaps the second solution does?

    Well, the code in the post doesn't handle DST at all. I'm not sure about MS's implementation, I'd assume that it does handle it though. As for gmtime, I'm not sure if that's a locale that participates in daylight savings time offsets. The localtime function will do it automagically if you're in a locale that uses DST, and won't if you're not, provided of course that you've correctly set up your time zone/locale in the application's environment.

    As for the offset from 1900 thing, I'd imagine it was decided on for the purposes of efficiency and longevity.

  • AdT (unregistered) in reply to Tes
    Tes:
    leap-year?? He's only hardcoding if February has 28 or 29 days.

    Huh? I may be missing the joke, but a leap year is a year where February has 29 days, by definition. It's the same thing.

    Tes:
    He should have used another four ifs to check if the year is congruent modulo 4 and modulo 400.

    The rule in the Gregorian calendar is actually (pseudo-code):

    is_leap_year(x) = is_divisible(x, 4) and ( is_not_divisible(x, 100) or is_divisible(x, 400))

    Now if you do the math this means that the average year in the Gregorian calendar has 365.2425 days, which is quite close to the mean length of the tropical year (also called solar year), which is about 365.2422 days.

  • (cs) in reply to bob ardkor
    bob ardkor:
    reminds me of a recent post on a (french, sorry) SEO forum :

    http://www.webrankinfo.com/forums/viewtopic_80454.htm

    for those who don't speak french, the initial poster wants a php function that formats 2500000 to 2,500,000

    the first answer is an interesting home-made function.

    the second answer is, well, the right answer.

    The last post in that thread (according to the googlefish) is "The Wild Chair" saying "fortunately that I am not paid with the line of code :)"

  • (cs) in reply to Aquatoad
    Aquatoad:
    Anonymous:
    That results from a stupidity in Perl, as you can see if you look at the gmtime docs. The year element of the array returned by gmtime() is equal to the current year minus 1900.

    Fail! This is a "stupidity" that Perl inherited from Standard C/POSIX. As an aside, I've found that aside from basic math operations (off-by-one errors etc) the biggest atrocities in programming languages occurs in date manipulations.

    Of course, the real WTF is the calender system that makes date calculations so interesting in the first place.

  • (cs)

    I did something similar not too long ago when I needed the time and date with an offset in LSL. But at least I googled first, although the result of that was not a few stupid meaningless variable names short of a WTF on its own. But surprisingly enough, it worked:

    // Returns integers [second, minute, hour, day, month, year]
list GetTimeAndDate(integer unixtime, integer gmtoffset)
{
    integer seconds = unixtime;
    integer minutes = seconds / 60;
    integer hours = minutes / 60 + gmtoffset;
    integer days = hours / 24;

    integer julian_day = days + 2440588;  // Technically it's 2440587.5, but then we'd be adding 0.5 as the next step anyway

    integer W = (integer)((julian_day - 1867216.25) / 36524.25);
    integer X = W / 4;
    integer A = julian_day + 1 + W - X;
    integer B = A + 1524;
    integer C = (integer)((B - 122.1) / 365.25);
    integer D = (integer)(365.25 * C);
    integer E = (integer)((B - D) / 30.6001);
    integer F = (integer)(30.6001 * E);

    integer day = B - D - F;
    integer month = E - 1;
    integer year = C - 4716;

    if (month > 12)
    {
        month -= 12;
        ++year;
    }

    return [seconds % 60, minutes % 60, hours % 24, day, month, year];
}
  • (cs) in reply to bob ardkor
    bob ardkor:
    reminds me of a recent post on a (french, sorry) SEO forum :

    http://www.webrankinfo.com/forums/viewtopic_80454.htm

    for those who don't speak french, the initial poster wants a php function that formats 2500000 to 2,500,000

    the first answer is an interesting home-made function.

    the second answer is, well, the right answer.

    I wonder why (s)he is using a comma as a thousands separator - don't the French use "."?

  • (cs) in reply to makomk
    makomk:
    Aquatoad:
    Anonymous:
    That results from a stupidity in Perl, as you can see if you look at the gmtime docs. The year element of the array returned by gmtime() is equal to the current year minus 1900.

    Fail! This is a "stupidity" that Perl inherited from Standard C/POSIX. As an aside, I've found that aside from basic math operations (off-by-one errors etc) the biggest atrocities in programming languages occurs in date manipulations.

    Of course, the real WTF is the calender system that makes date calculations so interesting in the first place.

    So you have a better one all worked out then? One that accounts for the idiosyncrasies in the Earth's orbit, the changing seasons, the varying length of a solar day, makes a lunar month fit onto a solar calendar?

    The calendar we have is a good fit for the needs of the actual people on the planet. I realise that Julian days, or just abolishing the concept of days altogether and using the UNIX epoch would be easier for us programmers, but I don't think the rest of humanity would agree...

  • AdT (unregistered) in reply to misha
    misha:
    One that (...) makes a lunar month fit onto a solar calendar?

    A better calendar would realize that it cannot be done and just ignore the lunar cycles. The Gregorian calendar pretends to honor those cycles, but fails quite badly, so nothing would be lost if we abandoned the concept of months. The day should remain the basic unit of any calendar since day-night cycles are so fundamental to life on Earth. Years are also worth keeping because of the importance of seasons. But months? I know some women think that the moon controls their menstruation, some farmers think it affects their crops etc., but even if all that's true, for one, whatever lunar cycle you take (sidereal, synodic etc.), you end up with something that does not evenly divide the year at all, and secondly, it takes rather more to justify inclusion in a general calendar, so it's not worth the effort to try and shoehorn true lunar months into a solar calendar.

  • 28% genius (unregistered) in reply to Anonymous
    Anonymous:
    gsmalleus:
    my $year = $date[5]+1900;

    This doesn't seem very Y2K friendly.

    That results from a stupidity in Perl, as you can see if you look at the gmtime docs. The year element of the array returned by gmtime() is equal to the current year minus 1900.

    s/Perl/Unix/

  • passer bye (unregistered)

    you guys are missing an important point. consider how much programmers (even second rate programmers) get paid.

    now imagine a boss who knows little or nothing about programming, who asks his programmer to create this 19 second addition.

    If the guy submits that one line of code, the boss will think "This is what I pay so much money for ??? my teenage nephew could do this"

    If however a complicated function, which more or less works, is submitted, the boss pretends to understand it and goes away thinking his money is well spent.

  • AdT (unregistered) in reply to iMalc
    iMalc:
    Yeah, except you can't anyway because they don't occur at precise calculateable times, their coming is announced.

    Welcome to the Internet. :-p

  • Alcari (unregistered) in reply to passer bye
    passer bye:
    you guys are missing an important point. consider how much programmers (even second rate programmers) get paid.

    now imagine a boss who knows little or nothing about programming, who asks his programmer to create this 19 second addition.

    If however a complicated function, which more or less works, is submitted, the boss pretends to understand it and goes away thinking his money is well spent.

    Which is why paying programmers per line is a Bad Idea (tm) just don't the PHB's of the world.

  • Fuzz (unregistered)

    I've seen way too many date/time WTFs in my time.. but a favourite remains (in C#)...

    string dateString = DateTime.Now.ToString();

    string year = dateString.Substring(...); string month = dateString.Substring(...); string day = dateString.Substring(...);

    // now assuming where the year/month/day/etc are going to be placed in the string is already nuts because without locale specification you don't know what DateTime.ToString() is going to return

    DateTime nextMonth = DateTime.Parse(day + "/" + (int.Parse(month) + 1) + "/" + year);

    Even though .NET has a nice .AddMonths() function, the programmer declined to use it. Needless to say we had sudden failures in December.

  • csrster (unregistered) in reply to Fuzz

    I have my own coding standard for dates which is: "All dates are represented internally as unix timestamps. 'Real' dates/times are parsed/formatted for I/O only." So far it hasn't let me down, although I'm sure someone will now point out why this is a huge wtf in itself.

  • Knitpik (unregistered) in reply to erissian
    erissian:
    Theo:
    tmountjr:
    Am I missing something in the French back-and-forth that mentions money?
    No they don't mention money, ...
    j'ai des nombre (prix)

    Trans: I have a number (price)

    This made me laugh - it's a mistranslation of a typo. Should be: "J'ai des nombres (prix)" and "I have some numbers (prices)". Whaddya mean, "So what?"?

  • Rhialto (unregistered) in reply to skington
    skington:
    tmountjr:
    Any why on earth did he name his function "ToMoney"??? Am I missing something in the French back-and-forth that mentions money?

    The numbers he's formatting are prices.

    If that is so (well, in any case), in France (like most/all of Europe) it would have been 2.500.000,00 rather than 2,500,000.00 .

  • Hognoxious (unregistered) in reply to Rhialto
    Rhialto:
    If that is so (well, in any case), in France (like most/all of Europe) it would have been 2.500.000,00 rather than 2,500,000.00 .
    Depends. Is he formatting it for display or for inclusion in a file? Some EDI standards use the UK/US convention. It could also be a French company wanting to invoice a customer in the US in a format they'll understand.

    By the way, those aren't hypothetical situations - I've encountered both of them recently. Assumptions are the mother of all WTFs.

  • Hognoxious (unregistered) in reply to realmerlyn
    realmerlyn:
    Nobody has commented on 
    my $hour = $date[2]+4;
    yet. Apparently, he's computing localtime by hard-coding the GMT offset! That's gonna break, half of the year. Great.
    Actually, it'll be wrong nearly all the year, somewhere or other.

    Luckily there aren't too many major landmasses at that longitude in the Southern hemisphere.

  • Sgt. Preston (unregistered)

    I can figure out what the programmer was probably thinking in some parts of this code, but can anyone guess what was going through his mind when he wrote:

    if ($sec < 41){$sec = $sec + 19;}
else{
   $sec = $sec + 19 - 60;
...
}
    What's the significance of 41 seconds and 19 seconds?
  • (cs) in reply to Sgt. Preston
    Sgt. Preston:
    I can figure out what the programmer was probably thinking in some parts of this code, but can anyone guess what was going through his mind when he wrote: 
    if ($sec < 41){$sec = $sec + 19;}
else{
   $sec = $sec + 19 - 60;
...
}
    What's the significance of 41 seconds and 19 seconds?

    That code is equivalent (for positive $sec) to "$sec = ($sec + 19) % 60" - now do you get it?

  • Sgt. Preston (unregistered) in reply to Random832
    Random832:
    Sgt. Preston:
    I can figure out what the programmer was probably thinking in some parts of this code, but can anyone guess what was going through his mind when he wrote: 
    if ($sec < 41){$sec = $sec + 19;}
else{
   $sec = $sec + 19 - 60;
...
}
    What's the significance of 41 seconds and 19 seconds?

    That code is equivalent (for positive $sec) to "$sec = ($sec + 19) % 60" - now do you get it?

    Thank you, but no, I still don't get it. Why does he want to add 19 seconds? What happens 19 seconds after the actual time?

  • (cs) in reply to makomk
    makomk:
    Aquatoad:
    Anonymous:
    That results from a stupidity in Perl, as you can see if you look at the gmtime docs. The year element of the array returned by gmtime() is equal to the current year minus 1900.

    Fail! This is a "stupidity" that Perl inherited from Standard C/POSIX. As an aside, I've found that aside from basic math operations (off-by-one errors etc) the biggest atrocities in programming languages occurs in date manipulations.

    Of course, the real WTF is the calender system that makes date calculations so interesting in the first place.

    Be thankful you don't live in Turkmenistan, where the previous "president for life" renamed all the months, including January after himself and April after his mother. Or Venezuela, where the president created a new time zone and ordered the country to switch over to it less than a week after announcing it.

  • (cs) in reply to Sgt. Preston
    Sgt. Preston:
    Thank you, but no, I still don't get it. Why does he want to add 19 seconds? What happens 19 seconds after the actual time?

    That was just the specification of the job he was given; from the article:

    FTFA:
    Like Yuri’s predecessor. He was presented with a simple problem: add nineteen seconds to the current date/time in Perl.

    As for a suggestion of where that requirement may have come from, Alexgeig suggests above:

    alexgieg:
    I think I discovered why the software must add 19 seconds to the time. From Wikipedia:
    ". . . computers need not use UTC. They could use either TAI or GPS time and convert to UTC or local civil time as necessary for output. GPS time is an especially convenient choice as inexpensive GPS timing receivers are readily available and the satellite broadcasts include the necessary information to convert GPS time to UTC. It is also easy to convert GPS time to TAI as TAI is always exactly 19 seconds ahead of GPS time.

    "Examples of systems based on GPS time include the CDMA digital cellular systems IS-95 and CDMA2000."

    Captcha: vern (???)

    HTH. HAND.

  • some canadian dude (unregistered) in reply to realmerlyn
    Apparently, he's computing localtime by hard-coding the GMT offset! That's gonna break, half of the year
    er... not all places use daylight savings eh.. For example, most of Saskatchewan Canada is GMT-7:00 year 'round.

    imho.. all servers and databases should stick with GMT ... and display the local time correctly using the proper library to deal with headaches like time zone offsets and daylight savings..

    The programmer isn't a "newfie" either.. those folks live in an area that is GMT-3:30 (or GMT-2:30 during daylight savings).... don't ask... /shrug

  • Maliron (unregistered)

    I believe this should be filed under "PWN'd"

  • Rory the Turbulent (unregistered)

    The real WTF is the pesky fact the Earth takes 365 days, 6 hours, 9 minutes, and 9 seconds to complete an orbit around the sun. It really should be 360 days. So all we need to do is move the entire Earth-Moon system a few thousand kilometres closer to the sun and all these pesky calendar problems will be resolved.

  • Stuart Gall (unregistered)

    It depends on the severity of the application. But your code wont actually work if there is a leap second. Neither does the protracted version of course.

  • Yann Droneaud (unregistered) in reply to Someone

    Indeed, a minute could be 61 seconds.

    Coordinated Universal Time (UTC) has leap second used to match day duration increase due to Earth rotation slowing down.

  • Anonymous (unregistered)

    Um: sub factored_time_calc { shift if blessed($[0]); return DateTime->now->add(seconds => $_[0]); }

  • Chuck Lester (unregistered) in reply to csrster
    csrster:
    I have my own coding standard for dates which is: "All dates are represented internally as unix timestamps. 'Real' dates/times are parsed/formatted for I/O only." So far it hasn't let me down, although I'm sure someone will now point out why this is a huge wtf in itself.

    As a programmer, I usually tend to use the same approach. However, there are certain cases where this might be a problem, for example, when you store these timestamps in a database, and you intend to use a different tool to create, for example, reports by month of the same data, or simply browse and query the data by date, with any SQL tool. Of course the queries can be done by calculating a timestamp range, or converting data "on the fly" but the use of date/time sql functions is often a little easier and I guess even optimal for the database.

Leave a comment on “All For 19 Seconds”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article