• Hanzito (unregistered)

    A frist thing happened.

  • (nodebb)

    A thrid thing happened

  • DQ (unregistered)

    And then a scnd thing

  • (nodebb)

    This is one of those so obvious so dumb things that it's hardly WTF worthy.

    I don't know those particular syscalls, but was there any good reason they couldn't have simply replaced the call to the first with the call to the second then output all the date & time components from that result value?

    Looks to me like another example of doing without thinking. And of "the best change is the smallest change". Both of which are shortsighted crap pushed by ignorant managements. Faster isn't better when you have to do it twice to get it right. Or more.

  • Hanzito (unregistered) in reply to WTFGuy

    This is one of those so obvious so dumb things that it's hardly WTF worthy.

    You may think so, but the other day, I saw an announcement for some kind of "no code" declarative thingy that translates to SQL and JavaScript (and something else), which was vibe-coded and had this exact same error in the example on the front page. Nobody seemed to notice it. So there's that...

  • (nodebb) in reply to WTFGuy

    I don't know those particular syscalls, but was there any good reason they couldn't have simply replaced the call to the first with the call to the second then output all the date & time components from that result value?

    No, there wasn't a good reason. That's why it's a WTF and posted on this site.

  • (nodebb)

    At least this code is pretty easy to fix:

    #include <cstdio>
#include <ctime>
#include <sys/time.h>

int main() {
    struct timeval now_tv;
    gettimeofday( &now_tv, NULL );
    struct tm* now_tm = gmtime( &now_tv.tv_sec );
    
    printf(
        "[%04d-%02d-%02d %02d:%02d:%02d.%06d] Foo\n",
        now_tm->tm_year + 1900,
        now_tm->tm_mon + 1,
        now_tm->tm_mday,
        now_tm->tm_hour,
        now_tm->tm_min,
        now_tm->tm_sec,
        (int) now_tv.tv_usec
    );
    
    return 0;
}

    A couple things I noticed in the original code that's probably from anonymization: now_tv was declared on the stack but its members accessed via -> instead of . and time(); was being called without an argument (often just NULL), both of which result in compiler errors.

  • (author)

    This (wasn't, but) looks like the kind of code an LLM might write and probably skates through code review. It's certain to pass all but the most thoroughly mocked-out testing. It sure is a shame to have to write many many manhours of time-taxed test code where a little bit of "be careful and pay attention" would suffice.

  • Back to the 1990s (unregistered)

    Fixed just this kind of error back in about 1991 or 1992.
    Was a utility that read a collection of data for the logs in the NOC and created a report. Initial bug was reported as certain days near midnight would end up on the later side of midnight. Fixed with just one call to now=time() and kept using time().
    The code base was C. The network was late-1980s packet switching. No pipes, tubes or information super highway off-ramps yet.

  • (nodebb)

    I was fully expecting every component of the time stamp to be drawn from a separate call to get the current time. From what I've seen here, and some places I've worked, that wouldn't surprise me.

  • Westy (unregistered)

    Yeah, been there done that as the saying goes.

    We were trying to get a sense of how long it took certain concurrent processes to run (on a VAX emulator, for shits & giggles). Some other dude had written the timestamps to the logs, and it was my task to analyse the logs and make sense of it. This was a delightfully simple busy-job in good old Fortran 77 (I was on a lucrative contract being paid to do a whole lot of not much, which was a WTF in its own right; sometime I'll post the story).

    And yes indeed, sometimes the timestamps would appear in the log in the wrong order. The perpetrator of the over-engineered and over-complicated code that created those timestamps swore blind that "there's a bug in the Open VMS", so we dutifully put a bodge in place when those logs indicated that a process ran in negative time.

    Took a while of studying his code and comparing what he'd done against what the manual described, but eventually uncovered the boner. Kept me happily "busy" (and therefore unbothered) for a week or so.

    Ah, happy days.

  • FTB (unregistered)

    I'm old enough to remember when Windows time functions gave different results depending on which CPU core the thread was currently running on.

    Two consecutive calls to high precision time functions like QueryPerformanceCounter() could indeed go backwards.

  • 516052 (unregistered) in reply to FTB

    And you should be happy about it. Time going backwards is what Einsteins equations postulate would be the result of traveling faster than the speed of light. Therefore, CPU time going backwards clearly means you must have simply had too fast a CPU. Must be all that alien technology they keep saying they will unearth any day now for the last ever.

  • Gumpy Gus (unregistered)

    Reminds me of MSDOS where on the IBM PC at midnight the clock would be off by like 55 milliseconds so there was code to back up the time counter by that much at midnight. So time could go back to the previous day. I noticed this as my program hung because it wasn’t expecting for time to go backwards.

  • Gilbert (unregistered)

    FULLZ UPDATED 2026 USA UK CANADA SSN NIN SIN INFO with ADDRESS DL Photos front & back with Selfie Passport Photos IT|SP|RUS|AUS|BR|FR amny Countries DL photos available

    Children FUllz USA 2011-2023 Young & Old age FUllz 1930-2010 High CS Pros 700+ Comapny EIN Business Fullz LLC EIN Docs with DL Dead Fullz CC with CVV & Billin Address

    NIN Fullz with Address NIN Fullz with address Sort Code & Account number NIN UK Fullz with DL UK DL photos front back with Selfie UK Passport Photos UK CC fullz

    SIN Fullz with Address Canada DL Photos Front Back with Selfie CA Passpoprt Photos CA Email & Phone Number Active Leads Live CA Fullz

    Germany|Spain|Australia Fullz with Address & DOB Email Leads (Forex, Crypto, Casino, Investors, CEO's, Crypto, Crypto Exchanges) Sweep Stakes Active Combos & B2B Leads

    Tools & Tutorials available Carding Cash Out Scripting Spa--mming SMTP RDP C-panels Shells Web-Mailers SMS & Email Bulk Senders Look-Up Tutorials

    Telegram@killhacks - @ leadsupplier What's App - (+1) 727..788..6129 TG Channel - t.me/leadsproviderworldwide Discord - @ leads.seller VK Messenger - @ leadsupplier Signal - @ killhacks.90 Zangi - 17-7369-4210 Email - exploit.tools4u at gmail dot com https://about.me/gilberthong

    Many Other Stuff available in our shop Active & Live Fullz with guarantee Providing Replacements if anything found invalid Available 24/7

    #fulz #leads #emailleads #sweepstakes #cryptoleads #casinoleads #ssnleads #dlphoto #usaleads #canadaleads #fullzusa #fullzuk #whatsapp #facebook #activeleads #ccshop #cvvdumps #usadocs #highcreditscorefullz #eincompanydocs #kycstuff #infokyc #validfullz #validvendor

  • (nodebb) in reply to Gumpy Gus

    I do remember that 55ms limitation (how often the CPU is interrupted to update the time in the BIOS) on those early PCs. What I am really wondering is how 55 milliseconds could result in a noticeable hang, as it would be before midnight for a smaller span than it takes to blink. Did your program just stop checking the time?

Leave a comment on “Well Timed Double Checking”

Log In or post as a guest

Replying to comment #690840:

Log Out

« Return to Article