• (cs) in reply to SpyderMan

    This reminds me of an old cow-orker.

    Whenever I showed him something, he watched intently, took copious notes and, sometimes, even recorded the instructions to tape!

    That alone is not the issue. No, the issue came when he tried to apply what he recorded in "The Real World"(tm).

    If, in the process of carrying out the instructions, if something unexpected happened, even if the screen had a huge red flashing warning saying "WARNING! Pressing Enter will erase this system and all conected subsystems!", if his instructions said "Press Enter..."

    Yup. He would.

  • Pap (unregistered) in reply to SpyderMan

    Some RDBMSs accept dates such as 2006-10-00 (beginning of October) and will happily use such dates to perform accurate calculations and ranges in queries.

    If a database really wanted to, it could perform a calculation of Sept 31 => Oct 1 on the fly.

    Although from a programming point of view, you're better off forcing the user to think twice about what the hell he's entering.

  • (cs) in reply to WeatherGod
    WeatherGod:
    Anonymous:
    From a logical point of view (nevermind the fact that computer systems don't accept it): Explain what's so wrong about calling Sept 31 the same as Oct 1, if it's OK to call Wednesday 24:00 the same as Thursday 00:00 (which is officially acceptable, but not commonly done).


    Isn't it a lot like how 361 degrees is a valid measurement of angle, even if a circle only has 360 degrees?  While it wouldn't make much sense as an input value from the start of a series of calculations, these values can arise during calculations, and must be accepted in order for the rest of the calculations to finish.  Same thing for -90 degrees being the same as 270 degrees.  Maybe September 31st would arise as a result of some date math, but should be normalized before displaying.



    Maybe I'm the king of France.
    Maybe you're my long lost twin brother.
    Maybe, maybe, maybe;

    What kind of date math are you suggesting where this would arise? If a person is hand-computing this, they certainly won't come up with 9/31. And even the most basic date class, should know how many days are in a month and add days appropriately.

    I can't believe this many posts have been made because  it was uttered that Sept. 31 is not a valid date. I love being pedantic as much as the next guy but you people need to cut it out.

    sincerely,
    Richard Nixon
  • (cs) in reply to foonly
    Anonymous:
    Reminds me of the time a customer (name withheld) told us our instrument was giving a high error rate.  I had to fly to Minnesota in winter with test gear, drive over to this company and debug the instrument.  I walked in and saw they had the instrument plugged in on one side of the room and the computer on the other.  It was a different AC line on a different phase.  Plugging both into a common outlet strip solved their problem, which was that the signals were single-ended, so ground noise was killing them.

    When I got back, Customer Support didn't believe me.  "Ground is ground."  I put a high-impedance AC voltmeter between ground pins on two outlets in our office and it read 60V.  After that, they listened to me.

    That sounds familiar. I used to work at a mechanical testing lab. One of our major tools is a load frame: basically, a hydraulic press with sensors to report on the load and deformation of whatever we were squashing or stretching. Normally, the deformation sensor output would fluctuate by about 0.001% strain, and since strain measurements in the test are supposed to be monotonically increasing, I'd set up the software to simply ignore any output drops of less than 0.01%. One day, though, the output started fluctuating by about 0.5% -- an amount far greater than the signal level. The company that made the sensor couldn't find anything wrong with it: on their calibration system, it worked perfectly. I couldn't find anything wrong with the software.

    One of the other technicians found the problem by hooking an oscilloscope to the electrical mains. It turned out that one of the tools out in the machine shop, an EDM cutter, was generating huge amounts of noise on all three wires, and our test system was sharing a ground circuit with it.

  • (cs) in reply to SpyderMan
    SpyderMan:
    Sorry mate, but those instructions were wrong.  Laugh all you want, but the WTF is in the instructions.  I could write a script to produce those instructions and you got them wrong!!!

    <font face="Times New Roman">
    </font><font face="Times New Roman" size="3">Snoofle never said the instructions weren't wrong, so don't put words in his mouth.  He was simply pointing out that the testers were jackasses to waste time.  How the fsck long were they going to sit there being paid with tax money?  Slackers.

    </font><font face="Times New Roman" size="3">ok
    dpm</font>
  • (cs)

    I'd wager to say there were more comments about my September 31st problem than the original DailyWTF post.

    Sorry, didn't mean to cause this kind of a hubbub. I admit it was an oversight on my part in keeping my regexp too simplified, assuming users would refrain from entering dates that didn't actually exist.

    You just have to wonder at what point it becomes wasteful to try to prevent user errors that shouldn't happen in the first place. The user should have some responsibility for entering information appropriately. But then again it's like the old saying goes, try to make a system idiot-proof, they'll just make a better idiot.

  • (cs)

    That reminds me of something.

    This story might not be a big WTF if some background information was considered regarding the UNION.  Not the operation of sets, but the guys work with you and, in some special cases, get in the way of the management of your company.

    My dad works in an air-craft component assembly line as a quality inspector.  His tools include a pen, a small mirror on a retractable stick, and a notepad.  If he's about to do anything that requires any tools other than the 3 listed above, he's in violation with the contract.

    In the same place he is working now, there has been a case where the inspector saw a loose screw, he documented it, and helped the technician to tighten it up.  The technician found out about it and made a formal complain to the union, stating that this inspector was endangering his job.  The technician actually won the case and the inspector received a warning letter of some sort.

    Yeah, in places where Union gets in the way of management at every possible turns, this should not be a WTF. 

    But seriously, instead of fixing the small problem on sight, by going through all the paperwork and let the issue passed up and then back down on the hierarchy, it really doesn't save money and ultimately the union members will suffer for the loss and waste of resources in the process, I really don't see how the Union protects the workers in cases like this.

    Then again, some people just need to create some sense of superiority on the things they do in order to survive...  but that's just me.

  • (cs) in reply to guitarfox

    I worked for a large Mfg. firm writing db apps in Clipper (yes, it was THAT long ago) and doing whatever else they needed me to do at the time. Our Lan was all BNC with a span between 2 large tin buildings about 30' up in the air running from roof to roof through a steel pipe suspended between the buildings by some wire.

    We had a big thunderstorm move through and an indirect hit sent enough of a charge through the suspended cable to take out 9 workstations with damage ranfing from fried NIC's to burning quarter sized holes through some very expensive Compaq computers!

    I was tasked with finding something to lessen the damage should this ever happen again and I came up with some nifty BNC supressors that mount betwin the NIC and the BNC "t" that had a Ground wire that went on the closest ground. I was going around to all our systems installing these and was prevented from simply screwing the Ground wire to the nearest ground because only a Union Electrician could do that! Fine. I installed the supressors on ALL the computers and informed my boss when I was done and he turned the job of grounding them to the shop steward.

    A month or so goes by and we have another thunderstorm. Guess what happened? Yup. The same damned thing as before because the Union Electrician hadn't gotten around to hooking up ANY of the ground wires!

  • (cs)
    Anonymous:

    You just have to wonder at what point it becomes wasteful to try to prevent user errors that shouldn't happen in the first place. The user should have some responsibility for entering information appropriately. But then again it's like the old saying goes, try to make a system idiot-proof, they'll just make a better idiot.

    If you are building any kind of secure multiuser system, user input validation is critical, since some of the worst security issues occur as a result of insufficient user input validation.  For web apps, see:

    http://www.owasp.org/index.php/OWASP_Top_Ten_Project

    It's also a user-friendliness issue.  If you let your users enter arbitrary data and let the code arbitrarily normalize it to a valid value, you will sometimes get the wrong result.  With one toolkit we use, the import data tool took the dates from our records and silently munged them into B.C. dates.  Needless to say, we definitely did not want B.C. dates, and the dates did not look anything like B.C. to the naked eye.  A helpful error, complaining that our dates were malformed, would have been much nicer. 

    It's also important to realize, as someone else already pointed out, that invalid data is almost always ambiguous.  Does Sep 31 mean that the user wanted the day after Sep 30, in which case the intent was for Oct 1, or did the user want the last day of September, in which case the intent was for Sep 30?

    Fun fact: we have, in the past, been bitten by "date -d 'now -1 month'" (where date is gnudate) at the end-of-month in report scripts, because the author of the surrounding script assumed it would normalize to the end-of-month, and it didn't.  We ended up having to do complicated things to work around this problem.


    Oh, don't get me wrong, user input validation is absolutely critical because of the possible ambiguities that can result from inputs of September 31st.  What I was refering to is the internal, intermediate representations during some date manipulations.  For example, if I set up a date struct to have Sept. 3 and I want the date that is 5 days before that, there will be an intermediate representation of Sept. -2 before the normalizing step that will result in Oct. 29.  User input and output should ALWAYS be normalized to make sense to the user.
  • (cs) in reply to Digitalbath
    Digitalbath:

    No, actually that example is not relevant.  It's like saying 11 is equal to the string "dog poop" in my randomly on-the-fly generated counting system. 



    Unfortunately for you, the hexadecimal system isn't random, nor was it generated on-the-fly. And even if it was, substituting arbitrary symbols for values (so as to emphasize the relationships) is exactly what algebra does. Would you say algebra is random?

  • (cs) in reply to ans:00101010
    ans:00101010:

    This reminds me of an old cow-orker.

    Whenever I showed him something, he watched intently, took copious notes and, sometimes, even recorded the instructions to tape!



    He he... See my recent blog entry about this. I apologize for the plug; I'd copy the text here, but it's too long.
  • (cs) in reply to Jackal von ÖRF
    Jackal von ÖRF:
    At my previous work place there was a standard PC where the file shares, customer database and some web applications ran. Occasionally it happened so that the cleaner unplugged the computer, which meant that nobody could access the services until somebody came to the office the next morning/Monday and started up the computer.

    <FONT face=Tahoma>This reminds me of a tale story I've heard:

    A certain hospital room was thought to be jinxed because every patient on that room mysteriously died everytime the clock strikes 11pm. Doctors were alarmed and sought help from police, investigators, paranormal experts, etc...

    They checked the nurses attending to those patients, the medications that were issued, equipments used, presence of lost spirits, etc... But found no faults...

    This happened again and investigators decided to stay in that room and see for themselves if someone (or something) really killed the patients occupying the room...

    10:30pm, Everything looks normal...

    10:45, Still nothing unusual...

    10:55, Not even a wierd noise...

    Finally, the clock stroke 11... investigators watched in horror as the janitor came in and started pulling respirator plugs from their sockets in order to plug-in his vacuum cleaner...

    Scary...



    </FONT>
  • This is a name (unregistered) in reply to makomk

    /dqn/ on 4-ch.net, I think becauseitswinter might too. Currently 1993-09-4756 04:31

    Time hard to validate properly, weird days such as Februrary 30th will cause havoc. Leap seconds? Daylight savings times moving around?

  • (cs) in reply to Roman

    Anonymous:
    HeroreV:
    [Si]dragon, I've never before read such extreme bullshit.

    September 31, 2005 is also known as October 1, 2005.

    No, it's not.

    Technically, there is nothing wrong about that date, it simply is not in its most simplified form.

    It's wrong.

    Afterall, dates are just length values (pick your precision) on some predefined offset, even when not dealing with a computer.

    Length is a measurement of physical dimension. It is never a measurement of time.

    But in this case, it is purely a style issue.

    No it's not.


    I guess you haven't been introduced to space-time yet.  Also the dictionary gives a definition for length: duration or extent in time.

    You lose.

    Time doesn't exist. That is to say time as in space time doesn't exists, therefore space-time itself doesn't exists.

    We live in the ever unfolding present. Our perception of time is merely the interpretation of patterns of matter-energy (the everystuff oft confused with space-time, which I prefer to call chi cause it's easier to say). The presence of these memory structures manifests itself in thought as time, but as thought is confused perception, this manifestation is merely an illusion.

    You lose, but don't get upset, this is the best possible outcome in the best possible universe.

  • PHP coder (unregistered) in reply to HeroreV
    HeroreV:
    [Si]dragon, I've never before read such extreme bullshit.

    September 31, 2005 is also known as October 1, 2005.

    No, it's not.

    Technically, there is nothing wrong about that date, it simply is not in its most simplified form.

    It's wrong.

    Afterall, dates are just length values (pick your precision) on some predefined offset, even when not dealing with a computer.

    Length is a measurement of physical dimension. It is never a measurement of time.

    But in this case, it is purely a style issue.

    No it's not.


    HeroreV, you're a dick. You missed the point completely. Go read about IEEE floating point standards compared to previous attempts at floating point representation if you dont get what he's saying...

    Also, so the phrase "a length of time" is referring to a physical dimension?

    argumentitive wanker...
  • Redshirt Coder (unregistered) in reply to foonly
    Anonymous:
    Reminds me of the time a customer (name withheld) told us our instrument was giving a high error rate.  I had to fly to Minnesota in winter with test gear, drive over to this company and debug the instrument.  I walked in and saw they had the instrument plugged in on one side of the room and the computer on the other.  It was a different AC line on a different phase.  Plugging both into a common outlet strip solved their problem, which was that the signals were single-ended, so ground noise was killing them.

    When I got back, Customer Support didn't believe me.  "Ground is ground."  I put a high-impedance AC voltmeter between ground pins on two outlets in our office and it read 60V.  After that, they listened to me.


    10: connect wires
    20: read around 60V
    30: unplug wires from voltmeter
    40: friendly ask $STUPID to hold them a second...
    50: ...

    Reminds me of a screw-up i saw once in a HW design.
    A serial line connection on board was using one wire and was keeping bits like gov keeps tax euros.

    They did not find out why and tried to fix it by using a crc and error recovery protocol over the line. When i looked at the boards and asked for the syncronisation between the devices i was told by the hardware guy that they ran on the same clock, so no sync was needed. Well, each chip had it's own nice shiny oscilator, driving several MHz into the chip as well as into any other thing nearby.

    But since they were all labeld the same, no sampling errors were to expect, or were they???
  • gaz (unregistered) in reply to Redshirt Coder

    You're all mad.  There is no such date as 31st September!  The calendar is a construct invented by human beings and it doesn't contain 31st September.  Any computer that asks for a date is modelling the calendar and again it shouldn't be happy with 31st September.  It's pseudo-philosophical nonsense to argue otherwise.

  • (cs) in reply to Redshirt Coder
    Anonymous:
    10: connect wires 20: read around 60V 30: unplug wires from voltmeter 40: friendly ask $STUPID to hold them a second... 50: ...
    60: $STUPID gets to end of shift, drops wires, and goes home.

    A high-impedance voltmeter may be able to see 60V, and that 60V may cause sensitive electronics some problems, but if it was going to cause any sort of problem in every day use, then there'd be hazard warning labels on every appliance in your house, and you'd never be allowed to pick up an electric kettle without using rubber gloves.

  • (cs)

    We all know, this is a most common problem and the reason for that is in most cases the cleaning maid who just needs a wall socket to plug in her vacuum cleaner and doesn't bother at all with those WTFy "Off Limit" restrictions cause she just has to do her job. This case happened frequently in the server room at my university. We learn about that: Just have always enough free plug sockets over all your server room! Or let the geeks do the cleaning.

  • (cs) in reply to Redshirt Coder
    Anonymous:

    Reminds me of a screw-up i saw once in a HW design.
    A serial line connection on board was using one wire and was keeping bits like gov keeps tax euros.

    They did not find out why and tried to fix it by using a crc and error recovery protocol over the line. When i looked at the boards and asked for the syncronisation between the devices i was told by the hardware guy that they ran on the same clock, so no sync was needed. Well, each chip had it's own nice shiny oscilator, driving several MHz into the chip as well as into any other thing nearby.

    But since they were all labeld the same, no sampling errors were to expect, or were they???


    WTF are you talking about? The internal RC oscillator? That's not a "screw-up", thats a "change your line of work you dont even grasp the basics".
  • (cs) in reply to xrT
    xrT:
    Jackal von ÖRF:
    At my previous work place there was a standard PC where the file shares, customer database and some web applications ran. Occasionally it happened so that the cleaner unplugged the computer, which meant that nobody could access the services until somebody came to the office the next morning/Monday and started up the computer.

    <font face="Tahoma">This reminds me of a tale story I've heard:

    A certain hospital room was thought to be jinxed because every patient on that room mysteriously died everytime the clock strikes 11pm. Doctors were alarmed and sought help from police, investigators, paranormal experts, etc...

    They checked the nurses attending to those patients, the medications that were issued, equipments used, presence of lost spirits, etc... But found no faults...

    This happened again and investigators decided to stay in that room and see for themselves if someone (or something) really killed the patients occupying the room...

    10:30pm, Everything looks normal...

    10:45, Still nothing unusual...

    10:55, Not even a wierd noise...

    Finally, the clock stroke 11... investigators watched in horror as the janitor came in and started pulling respirator plugs from their sockets in order to plug-in his vacuum cleaner...

    Scary...



    </font>


    The real WTF is a hospital were the intensive care unit is vacuum cleaned at 11 in the evening. Patients should rest.
  • AndyC (unregistered) in reply to SpyderMan

    Anonymous:
    Sorry mate, but those instructions were wrong.  Laugh all you want, but the WTF is in the instructions.  I could write a script to produce those instructions and you got them wrong!!!

    Yes, the instructions were wrong but the tester should have read the next line, not seen what it said he should have expected and filed a bug, not sat around doing nothing.

  • (cs)

    Thirty-one has September... wrote the following post at 09-07-2006 10:20 PM:
    Anonymous:
    Fine, here's an argument. Go and find any wall calendar, datebook, calendaring software, checkbook register, ANYTHING with a calendar printed on it and show me September 31st.
    http://www.lawyersweeklyusa.com/archives/pdf/promo/CalendarUSA.pdf#search=%22%22september%2031%22%20calendar%22 

    Oh, but that's September 31, 2006.  Weren't we discussing how there was no September 31, 2005?

    Maybe 2006 is a September-31-leap kind of year.

  • mc2p4 (unregistered)

    Classic, Absolutely, Classic!  I usually don't make it to 10 either (one-Mississippi, Two-etc.)

     

    p4

  • (cs) in reply to This is a name

    This is a name wrote the following post at 09-08-2006 6:46 AM:
    Currently 1993-09-4756 04:31 Time hard to validate properly, weird days such as Februrary 30th will cause havoc.

    I can imagine how February 30th would cause havoc, but when was the last time we had a February 30th?  I mean, we're not talking about B.C. dates here, we just need to go back to 1993 in our date computations -- and by 1993, the Berlin Wall had come down, and the Web had been invented, right?

  • (cs)
    Anonymous:

    You just have to wonder at what point it becomes wasteful to try to prevent user errors that shouldn't happen in the first place. The user should have some responsibility for entering information appropriately. But then again it's like the old saying goes, try to make a system idiot-proof, they'll just make a better idiot.

    If you are building any kind of secure multiuser system, user input validation is critical, since some of the worst security issues occur as a result of insufficient user input validation.  For web apps, see:

    http://www.owasp.org/index.php/OWASP_Top_Ten_Project

    It's also a user-friendliness issue.  If you let your users enter arbitrary data and let the code arbitrarily normalize it to a valid value, you will sometimes get the wrong result.  With one toolkit we use, the import data tool took the dates from our records and silently munged them into B.C. dates.  Needless to say, we definitely did not want B.C. dates, and the dates did not look anything like B.C. to the naked eye.  A helpful error, complaining that our dates were malformed, would have been much nicer. 

    It's also important to realize, as someone else already pointed out, that invalid data is almost always ambiguous.  Does Sep 31 mean that the user wanted the day after Sep 30, in which case the intent was for Oct 1, or did the user want the last day of September, in which case the intent was for Sep 30?

    Fun fact: we have, in the past, been bitten by "date -d 'now -1 month'" (where date is gnudate) at the end-of-month in report scripts, because the author of the surrounding script assumed it would normalize to the end-of-month, and it didn't.  We ended up having to do complicated things to work around this problem.

    Reading your response actually made me say WTF.

    I know my opinion makes me look like a lazy programmer, and if we were talking about a secure multi-user system I'd agree with you.

    But in the case I was referring to, the task was simply to fulfill some quality assurance requirement to have a website that can track information. I've done stuff like this in the past, no one ever uses them.

    Furthermore I was restricted by time (which apparently doesn't exist, according to other posts) and by available funding. This was a project done on overhead with no customer backing, so I was told to whip it together as fast as possible. For the field in question, 99.9% of the time the users would go with the default value which was today's date, but I was told to leave it editable in case they needed to change it.

    Someone did change it, and used a day that didn't exist. Whatever their intent was, whether it was Oct 1 or Sept 30, is irrelevant. I had to revisit this project weeks later and spend an hour tracking down this bug and fixing it. So instead of a nice, simple regexp, I have a few nested if statements over a dozen lines all because someone didn't know that 30 days hath September.

    I'm just saying that you can only go so far to prevent user error. If someone meant to type 9/4/2005 and accidently hit the 1 to make it 9/14/2005, there's nothing you can do to fix that.

  • anonymous (unregistered) in reply to Manni
    Manni:
    But in the case I was referring to, the task was simply to fulfill some quality assurance requirement to have a website that can track information. I've done stuff like this in the past, no one ever uses them.


    3 lies of software:
     - Simply
     - Only
     - Temporal

    If somehome ask you for some code, and use 2 of these, run!. .run for the hills!, and never look again.

    Mate, your code whas poor, admit it and live with it. Is not like you will suffer ethernal pain or something.
  • Hillbilly Geek (unregistered)

    Heh. Well, at least now he can charge for the repair.

  • (cs) in reply to felix
    felix:
    Digitalbath:

    No, actually that example is not relevant.  It's like saying 11 is equal to the string "dog poop" in my randomly on-the-fly generated counting system. 



    Unfortunately for you, the hexadecimal system isn't random, nor was it generated on-the-fly. And even if it was, substituting arbitrary symbols for values (so as to emphasize the relationships) is exactly what algebra does. Would you say algebra is random?

    Unfortunately for you, you missed my point, but you made a solid effort.  I was not saying hexadecimal was random.  I was saying that Sep 31 is a random, made up date.  Therefore, converting 11 to a random representation in something made up and coming up with "dog poop" was a better analogy.

    Read slower and sound out words if you get stuck. 

  • (cs) in reply to Richard Nixon
    Richard Nixon:
    Digitalbath:

    Anonymous:
    No, actually the days are the same, just the system is different. His "system" seems to use 31 days in the month of September instead of the arbitrary 30. It's like saying 11 is equal to B. You just need to know that one system is decimal and the other is hex.

    No, actually that example is not relevant.  It's like saying 11 is equal to the string "dog poop" in my randomly on-the-fly generated counting system. 



    Wait a second...that's my counting system! You'll be hearing from my attorney. We're going to sue you for $dog poop,grass,bicycle,garbage can dollars!

    sincerely,
    Richard Nixon

    "$dog poop,grass,bicycle,garbage can dollars" is redundant.  You've set such high posting expectations for yourself, Mr. Nixon that I expect much better.  Get your game face on please. :)

  • The Captain Answers (unregistered) in reply to Roman

    Anonymous:
    HeroreV:
    [Si]dragon, I've never before read such extreme bullshit.

    September 31, 2005 is also known as October 1, 2005.

    No, it's not.

    Technically, there is nothing wrong about that date, it simply is not in its most simplified form.

    It's wrong.

    Afterall, dates are just length values (pick your precision) on some predefined offset, even when not dealing with a computer.

    Length is a measurement of physical dimension. It is never a measurement of time.

    But in this case, it is purely a style issue.

    No it's not.


    I guess you haven't been introduced to space-time yet.  Also the dictionary gives a definition for length: duration or extent in time.

    You lose.

    You mean, he wins.  We all win!!  He now has correct information and is a better person because of it ;^).

    We are all now extremely enlightened - I feel like having one big group hug.  Now if we all could simply warp into the realm of subspace where September 31st does exist, we'd all be happy campers.

    Or we could simply stay with the realm of elitist antagonists bouncing barbs full of attitude back and forth for simple entertainment.

    CAPTCHA is "captcha".

  • (cs) in reply to anonymous

    Anonymous:
    Manni:
    But in the case I was referring to, the task was simply to fulfill some quality assurance requirement to have a website that can track information. I've done stuff like this in the past, no one ever uses them.


    3 lies of software:
     - Simply
     - Only
     - Temporal

    If somehome ask you for some code, and use 2 of these, run!. .run for the hills!, and never look again.

    Mate, your code whas poor, admit it and live with it. Is not like you will suffer ethernal pain or something.

    Not as bad as your spelling and punctuation though.

    I suppose my first mistake was to put out an example of something I'd screwed up in the past. But you caught me, I did in fact screw it up. Nevermind the fact that in my first response I admitted to my mistake. Don't worry though, you've taught me that next time I should anonymously post comments that point out the flaws of others while not being comfortable enough with my own previous mistakes to actually contribute something to the conversation.

    Congrats to you, you won teh internets.

  • (cs) in reply to xrT
    xrT:
    Finally, the clock stroke 11... investigators watched in horror as the janitor came in and started pulling respirator plugs from their sockets in order to plug-in his vacuum cleaner...
    Don't know if that story is true or not, but there is a substantiated similar story in Harold Klawans' book "Trials of an Expert Witness" (some of which reads like a collection of medico-legal WTFs; it's a pretty good book). It's near the end, titled "Double Jeopardy" -- a transporter who had already been disciplined for negligence was told to bring a TV in to the ICU for a patient who was chronically ill but conscious. He disconnected the oxygen systems to plug in the TV and put the patient into a fatal coma.
  • Mr_Daemon (unregistered) in reply to Manni
    Manni:

    Anonymous:
    Manni:
    But in the case I was referring to, the task was simply to fulfill some quality assurance requirement to have a website that can track information. I've done stuff like this in the past, no one ever uses them.


    3 lies of software:
     - Simply
     - Only
     - Temporal

    If somehome ask you for some code, and use 2 of these, run!. .run for the hills!, and never look again.

    Mate, your code whas poor, admit it and live with it. Is not like you will suffer ethernal pain or something.

    Not as bad as your spelling and punctuation though.

    I suppose my first mistake was to put out an example of something I'd screwed up in the past. But you caught me, I did in fact screw it up. Nevermind the fact that in my first response I admitted to my mistake. Don't worry though, you've taught me that next time I should anonymously post comments that point out the flaws of others while not being comfortable enough with my own previous mistakes to actually contribute something to the conversation.

    Congrats to you, you won teh internets.



    You're being such a dick over this... Come on, both of you hug and exchange bytecode.
  • Jono (unregistered) in reply to HeroreV

    Users at my firm depend on this interpretation of dates.  E.g. they know that today is 9/25/2006, and they know that they want to enter a date 10 days from today.  It is less effort for them to enter 9/35/2006 than it is to do the mental arithmetic to translate that to 10/5/2006.  Why would they do that arithmetic when the computer is so much better at it?  This way they save a small amount of time, and when they do this hundreds of times a day that translates to a significant productivity gain, which is really the point of all this IT stuff.

  • The Captain Answers (unregistered) in reply to Jono

    Anonymous:
    Users at my firm depend on this interpretation of dates.  E.g. they know that today is 9/25/2006, and they know that they want to enter a date 10 days from today.  It is less effort for them to enter 9/35/2006 than it is to do the mental arithmetic to translate that to 10/5/2006.  Why would they do that arithmetic when the computer is so much better at it?  This way they save a small amount of time, and when they do this hundreds of times a day that translates to a significant productivity gain, which is really the point of all this IT stuff.

    LAZY_USER_DONT_TYPE_OCT5

    + PROGRAMMER_WRITES_CODE_FOR_CASE_SEP35 

    = BRILLANT!

    CAPTCHA = random

  • (cs) in reply to The Captain Answers
    The Captain Answers:

    Anonymous:
    Users at my firm depend on this interpretation of dates.  E.g. they know that today is 9/25/2006, and they know that they want to enter a date 10 days from today.  It is less effort for them to enter 9/35/2006 than it is to do the mental arithmetic to translate that to 10/5/2006.  Why would they do that arithmetic when the computer is so much better at it?  This way they save a small amount of time, and when they do this hundreds of times a day that translates to a significant productivity gain, which is really the point of all this IT stuff.

    LAZY_USER_DONT_TYPE_OCT5

    + PROGRAMMER_WRITES_CODE_FOR_CASE_SEP35 

    = BRILLANT!

    Users are never lazy. Programmers are, all too often. It's the task of a programmer to make programs that allow users to work as easy and fast as possible. If "9/35/2006" is what they need to accomplish this goal, who are you to refuse that?
    You should never underestimate the hidden costs of a user interface that causes the users more work than necessary. If a routine job takes 2 seconds longer and the users does it 100 times a day, and you have 20 people working with that program, that's more than one hourly wage  (say $30) wasted per day; it sums up to $7000 per year.

  • (cs) in reply to SpyderMan
    Anonymous:
    And if I input 27698th September, 1694 you'll expect the application to work out the date?

    Why not?

    Looks perfectly valid to me, just needs to be normalized.

  • mnature (unregistered) in reply to snoofle
    snoofle:

    Just after college, I worked at a DoD subcontractor. We had a rather complex piece of equipment that required an excruciatingly long sequence of steps for an acceptance test. The instructions ran something like this:

    Enter "abc"
Press "RUN"
<expect to see ...>
Enter "def"
Press "RUN"
<expect to see ...>
...
Enter "ghi"
<expect to see ...>
Enter "jkl"

    After watching a QA person (from the gov't) running through the test, I noticed that they were sitting idle for over an hour. I asked what the problem was. They told me that they entered "ghi" and were waiting for the output on the screen. I looked at the instructions and *yelled* "PRESS RUN". They informed me that the instructions didn't SAY to press run. All I could do was laugh.

    Reminds me of something I read about in Albuquerque, New Mexico.  Seems that most of the traffic lights were set to just go on a timer late at night, regularly switching the traffic flows.  However, one traffic light had an incorrect timer, so instead of changing every 30 seconds, it would change about every 4 minutes.  After this was pointed out, the traffic engineers said that it really didn't matter.  They were asked, quite reasonably, why it didn't matter.  They answered by asking a question:

    "Let's say you are driving, late at night, and get to a red light.  What do you do if it hasn't changed to green within 30 seconds?"

    "I'd look left and right, and then run the red light!"

    "You see, it doesn't really matter what the actual timing is set to."

    CAPTCHA = pacman (should have been WoW, but I'll accept pacman)

  • hank miller (unregistered) in reply to WeatherGod
    WeatherGod:
    Isn't it a lot like how 361 degrees is a valid measurement of angle, even if a circle only has 360 degrees?  While it wouldn't make much sense as an input value from the start of a series of calculations, these values can arise during calculations, and must be accepted in order for the rest of the calculations to finish.  Same thing for -90 degrees being the same as 270 degrees.  Maybe September 31st would arise as a result of some date math, but should be normalized before displaying.

    -90 degrees is NOT the same as 270 degrees. If you are on circle it is, but degrees is used for many other measurements based on trig. Plot out a sin wave, and you will notice that -90 degrees has the same value on the 'y' axis, but is in a different place on the 'x' axis. (I suppose some wise guy will now plot this with different axis)

    This is sometimes important. Radio is a sin wave with distortion added, subtract the sin wave, and the distortion is the signal. (This is very simplified, and not the common way of looking at radio)

  • (cs) in reply to [ICR]
    Anonymous:
    If I don't say it someone else will - Frankinstein is the creator, the monster wasn't given a name by Mary Shelley,. it was just called "monster" or "creature".

    He wanted to write that, but there was a Trojan on his computer that prevented it.

    Anonymous:
    September 31, 2005 is also known as October 1, 2005

    No, it is not. Every definition is, by convention. Every proposal to create or alter a definition ought to be sensible and useful.

    The conventional understanding of the "day of month" concept is that it is an integer between (inclusive) 1 and the length of the month in question. If no year is known, the maximum length of the month (e.g. 29 for February).

    So your new-fangled way to do "un-normalized" dates comes with a proposal to alter our definition of "day of the month". Since this involve some serious effort, the change should rather be worth that effort. But it's not.

    (In the following, I assume that your suggested new definition of "day of the month" is "an integer".)

    First, your definition is not useful, for several reasons:

    • Adopting it means we can no longer use some language-inherent redundancy for error detection.
    • It does not improve efficiency of communication. For example, "September 31, 2005" is no easier to communicate in verbal exchange than "October 1, 2005", not only doesn't it reduce the "sender"'s communication effort, but it substantially increases the receiver's effort, especially when the "day of the month" has a large absolute value. As far as digital communications are concerned, there are already more time- and space-efficient ways to communicate dates. Ways that do not require many date-processing applications to implement/use date arithmetic.

    Second, your definition is not sensible, because it can only be safely used when the reference year is know. How do you normalize January 40,000? There is no unique answer. The simple fact is that in our calendar, a date is not properly modelled as a sum of offsets to some imaginary date (let's say January 1, 1 CE). How many programmers have been burned by the false and disproven assumptions that:

    • a day has 86,400 seconds?
    • February has 28 days?
    • a year has 365 days?
    • one in four years is a leap year?

    Too many. But although it's possible to envision more sensible calendars than the Gregorian one we use, your definition of "day of the month" does not even attempt to fix the underlying issues with said Calendar. Instead, it just pretends they aren't there to haunt us. In short: Your suggested definition of "day of the month" requires a great amount of effort to adopt, it is logically flawed, and it is not useful. There is absolutely no reason for us to use it.

  • brain (unregistered) in reply to GoatCheez

    Maybe they realized that the machine which repeats old WTF's was turned off... and turned it back on again this morning? ;)

  • DanixDefcon5 (unregistered) in reply to Alexis de Torquemada

    Ah... Well if you want to see why a system shouldn't accept bad dates like that one...

     We had a weird problem with one of our reports. The data was in a MySQL server, but when transferring the whole thing to PostgreSQL, postgres just barfed.

     After hours of checking out the scripts and trying everything for the umpteenth time ... we found it.

     Someone had actually put one of the requisition dates as "April 31,2006".

     And MySQL let that happen. No, not May 1, 2006. The thing was actually stores as 2006-04-31 in the database.
     

  • . (unregistered)

    Frankenstein is the name of the doctor, not the monster!

  • AnonymousCoward (unregistered) in reply to Richard Nixon

    Richard Nixon:

    I can't believe this many posts have been made because  it was uttered that Sept. 31 is not a valid date. I love being pedantic as much as the next guy but you people need to cut it out.

     

    Mate, this is thedailywtf we're talking about. You could replace every other post with just the string "*sneer*" and nobody would even notice the difference.

     

    Moderator's note: I would, trust me. 

     

  • Anonymous (unregistered) in reply to Sean

    Sean:

    That most certainly is not grounds for being snippy.  If he had verified the machine was plugged in and running over the phone, he wouldn't have had to make the trip to the client site.

    he still would've had to go voer and plug it in b/c it was "off limits" to everyone except the three techs who were all on vacation...

    my monitor didn't start up once.  i called IT and ordered another monitor.  As he was bringing it up, i figured out it actually wasn't plugged in all the way on the monitor side (not the box side).

    whew!  i'm sure he got some laughs out of it, but if he had found it, you'd be reading about me in some random wtf comment...

  • Jessica (unregistered) in reply to ole gustie

    ole gustie:
    Anonymous:


    My fellow sysadmin and I always test each other's documentation by following it literally (with the other one watching over the shoulder).  It's the only way we can be sure that in a disaster someone else coming in cold without our head full of business knowledge and system quirks would be able to do the task in question (which is vital for any BCP type of things).


    Agreed...  but would your fellow sysadmin and you sit and stare at a screen for over an hour before thinkings that maybe, just maybe, something isn't quite right with the documentation?

    God no, that's where the "watching over the shoulder comes in".  Or the chance to jump in and say "You need to do this undocumented step" now, and then fix the documentation.

     

  • (cs)

    The real WTF here is that they set the profit margin so low that you probably didn't get paid for this.  If someone wants to pay me hundreds per hour to consult and all I have to do is re-plug in the system, i'm good.  If I have to do that for free, after wasting 2 hours... not so good.

  • Peter da Silva (unregistered) in reply to Jenn

    "Do you think it would be acceptable for someone to send you a birthday party invitation for November -347, 2007?"

     Yes.
     

  • itsmo (unregistered) in reply to anonymous
    anonymous:
    HeroreV:
    [Si]dragon, I've never before read such extreme bullshit.
    September 31, 2005 is also known as October 1, 2005.
    No, it's not.
    Technically, there is nothing wrong about that date, it simply is not in its most simplified form.
    It's wrong.
    Afterall, dates are just length values (pick your precision) on some predefined offset, even when not dealing with a computer.
    Length is a measurement of physical dimension. It is never a measurement of time.
    Length refers to a measurement of an interval.  It is OK to say "How long was the movie?", and expect an answer in units of time. But it is not OK to talk about "September 31".  The calendar is a "thing", and it has a precise definition, and that definition does not include nonsense such as "September 31".

    Exactly - it's crap. Could anyone seriously think a user would deliberately enter September 31 when they meant October 1 and expect the software to know what they meant. On the other hand if your trying to be smart and/or funny - don't give up the day job

Leave a comment on “That is Off-Limits As Well”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article