• Pippo (unregistered)

    Smart move Ebony, I think you have a successful carrier ahead of you.

  • graybeard (unregistered)

    Eh, easy solution: mobile numbers are negative, and any negative values shall be prefixed by 07.

  • (cs) in reply to graybeard
    graybeard:
    Eh, easy solution: mobile numbers are negative, and any negative values shall be prefixed by 07.
    Ah, a graduate from WTF-U is amongst us.
  • (cs)

    At least they didn't parse the numbers as octal.

  • noname (unregistered)

    Integrated Departmental Incident Outcome Tracker I.D.I.O.T.

    Very nice, indeed.

  • faoileag (unregistered)

    "Customer relations for software developers" 101: "If customer data causes problems with software, customer has to get different data."

    Wasn't there another article about mobile phone numbers just the other day? Something about truncating them to ten digits?

  • (cs)

    I'm reminded of some advice that I saw here sometime ago: if you would not do arithmetic with a field, do not store it as a numerical type (store it as a string).

  • faoileag (unregistered) in reply to martijntje
    martijntje:
    graybeard:
    Eh, easy solution: mobile numbers are negative, and any negative values shall be prefixed by 07.
    Ah, a graduate from WTF-U is amongst us.
    Definitely a graduate. A freshman would probably have come up with the idea that doubles were ideal for phone numbers, because the decimal point would make a nice seperator for the area code...
  • Robin (unregistered)

    You can get rid of the error message by automatically setting oversize numbers to 2147483647. It appears to be a popular phone number.

  • foo AKA fooo (unregistered)

    Just drop the last digit if the number is too long. It's unnecessary accuracy anyway.

  • CigarDoug (unregistered)

    The real WTF is that her manager didn't even TRY. Half the stories on the site are about stupid management decisions. Over half of those could have been solved by the developer, or their manager, doing their actual JOB and telling the powers that be that (a) The policy is stupid, and why; and (b) The policy needs to be changed, or the IT department is not going to be held responsible.

    Seriously, people need to grow a backbone. If it is really a stupid policy, not just one you disagree with, but blatantly stupid and contrary to reality and/or the laws of physics, don't tolerate it. Go over their heads, if they won't listen. Be a damn professional and defend the integrity of your work. If you are too new at your job to stick your neck out, then convince your boss to back you up. If they won't, then find another job and tell them exactly why you are leaving.

  • agbeladem (unregistered) in reply to Raedwald
    Raedwald:
    I'm reminded of some advice that I saw here sometime ago: if you would not do arithmetic with a field, do not store it as a numerical type (store it as a string).

    So any primary identification field should be a string? I know I'll never do an arithmetic operation on an ID field, yet I will still use a kind of integer if my DBMS doesn't handle Guids.

  • dba_wanna_be (unregistered) in reply to agbeladem
    agbeladem:
    Raedwald:
    I'm reminded of some advice that I saw here sometime ago: if you would not do arithmetic with a field, do not store it as a numerical type (store it as a string).

    So any primary identification field should be a string? I know I'll never do an arithmetic operation on an ID field, yet I will still use a kind of integer if my DBMS doesn't handle Guids.

    But you DO arithmetic on it -- don't you increment it by some set value when inserting a new row with a new ID? Gosh, I hope so!

  • QJo (unregistered) in reply to dba_wanna_be
    dba_wanna_be:
    agbeladem:
    Raedwald:
    I'm reminded of some advice that I saw here sometime ago: if you would not do arithmetic with a field, do not store it as a numerical type (store it as a string).

    So any primary identification field should be a string? I know I'll never do an arithmetic operation on an ID field, yet I will still use a kind of integer if my DBMS doesn't handle Guids.

    But you DO arithmetic on it -- don't you increment it by some set value when inserting a new row with a new ID? Gosh, I hope so!

    +1

  • Jim the Tool (unregistered)

    Rightly or wrongly, that's just the way the president's daughter did things. After all, she wasn't a highly paid consultant, just a lowly student.

    Also, I would be crafting an anonymous letter to print off and drop into the student newspaper to explain how stupid the people running the university are.

  • QJo (unregistered)

    We were maintaining an elderly FORTRAN app some years ago, which queued entries onto a print queue. All went well till our new printer software suddenly decided that all files would be printed in size order. So all the front pages came out, then all the back pages, then the report content, thereby causing a colossal manual overhead in collating the damn things, which previously had been printed envelope-perfect.

    The solution of course was to concatenate the complete report into one file before printing: front page, body, back page in that order, so that they would be directly ready once more for mailing.

    The next problem concerned how to uniquely create a report file. This was done by means of a timestamp, consisting of day, month, hour, minute, second, all in 2-digit format, concatenated into one integer.

    Suddenly, on the 22nd of October, all the print jobs failed.

  • John (unregistered) in reply to Medinoc
    Medinoc:
    At least they didn't parse the numbers as octal.
    I'd guess that their code actually tries to do that; that's why they remove the initial zero. And they only remove the first zero, because they "know" that the 2nd digit is never zero. Until management OKs some other department's request that phone "numbers" starting with "00" are to be used for some special purpose. Then more hilarity will ensue.
  • (cs) in reply to John

    I don't have anything funny to say, but if you want my opinion, please call me on my mobile at: -2147483648

  • Kasper (unregistered) in reply to QJo
    QJo:
    dba_wanna_be:
    agbeladem:
    Raedwald:
    I'm reminded of some advice that I saw here sometime ago: if you would not do arithmetic with a field, do not store it as a numerical type (store it as a string).

    So any primary identification field should be a string? I know I'll never do an arithmetic operation on an ID field, yet I will still use a kind of integer if my DBMS doesn't handle Guids.

    But you DO arithmetic on it -- don't you increment it by some set value when inserting a new row with a new ID? Gosh, I hope so!

    +1
    That is actually the most appropriate +1 comment, I have yet seen.

  • MrBester (unregistered) in reply to John
    John:
    Until management OKs some other department's request that phone "numbers" starting with "00" are to be used for some special purpose. Then more hilarity will ensue.
    Well, how else are you going to input international numbers? The field won't accept + as it is...
  • ¯\(°_o)/¯ I DUNNO LOL (unregistered)

    Supposedly some guy in Dallas took the MAXINT phone number intentionally. In any case, here's the googles on it so you be distracted while I get my ass off to work...

    https://www.google.com/search?hl=en&q=214-748-3647

  • Krunt (unregistered) in reply to Raedwald
    Raedwald:
    I'm reminded of some advice that I saw here sometime ago: if you would not do arithmetic with a field, do not store it as a numerical type (store it as a string).

    Which is yet another unrealistic generalisation that college graduates and evangelical DBAs like to quote without really thinking through.

  • gnasher729 (unregistered) in reply to John
    John:
    Medinoc:
    At least they didn't parse the numbers as octal.
    I'd guess that their code actually tries to do that; that's why they remove the initial zero. And they only remove the first zero, because they "know" that the 2nd digit is never zero. Until management OKs some other department's request that phone "numbers" starting with "00" are to be used for some special purpose. Then more hilarity will ensue.

    Foreign phone numbers start with 00. For example, USA called from the UK starts with 001.

  • John (unregistered) in reply to Krunt
    Krunt:
    Raedwald:
    I'm reminded of some advice that I saw here sometime ago: if you would not do arithmetic with a field, do not store it as a numerical type (store it as a string).

    Which is yet another unrealistic generalisation that college graduates and evangelical DBAs like to quote without really thinking through.

    How so? I've successfully used the argument on several projects that keeping such fields as strings rather than numbers at least eliminates the cpu overhead of the repeated conversion to and from string format. Also, such "numbers" always consist of a list of fixed-length fields, and you sometimes want to do arithmetic on them, such as calculating the next number for a new entry. If kept in integer form, detecting and correcting overflows when one field is incremented takes more code and cpu time than if you keep the data in string form. Then you can just convert a single field to integer when you want to increment it, and overflow doesn't modify an adjacent field.

    Also, I have a number of "account numbers" that contain letters. The US Social Security Administration does this, for instance, as do some credit unions. The letters are essentially qualifiers on the number field, for labelling closely-related accounts or marking them with some attribute. You can argue that this shouldn't be done, but when management decides it's The Thing To Do, life is easier for the programmers if they had decided to not store string data in numeric formats even though the strings contained only digits and looked like numbers at the time.

    So when is it advantageous to store strings that aren't really numbers in a numeric format? I haven't ever seen any real advantage to this. And note that it only matters to programmers, since they're the only ones that see the actual formatting. Arguments based on the feelings of non-programmers aren't really relevant to deciding what internal format to use.

  • American (unregistered) in reply to QJo
    QJo:
    We were maintaining an elderly FORTRAN app some years ago, which queued entries onto a print queue. All went well till our new printer software suddenly decided that all files would be printed in size order. So all the front pages came out, then all the back pages, then the report content, thereby causing a colossal manual overhead in collating the damn things, which previously had been printed envelope-perfect.

    The solution of course was to concatenate the complete report into one file before printing: front page, body, back page in that order, so that they would be directly ready once more for mailing.

    The next problem concerned how to uniquely create a report file. This was done by means of a timestamp, consisting of day, month, hour, minute, second, all in 2-digit format, concatenated into one integer.

    Suddenly, on the 22nd of October, all the print jobs failed.

    Easy Fix: Start with the month, not the day...

  • evilspoons (unregistered) in reply to American
    American:

    Easy Fix: Start with the month, not the day...

    Yeah, that makes more sense anyway. Who the heck goes "hey, let's sort data by the second most significant unit, then the most significant unit, then the third most significant unit..."

    Oh wait, I know who.

  • international WTF (unregistered)

    What idiot would use integeres for phone numbers in the first place.

    Try international numbers in that field: "+31......" awww too bad, can't fill in a +. Oh, let me preface the number with 00 then. Nope, integers don't start with "0".

    wah wah wah wahhhhh

  • Anon (unregistered) in reply to Pippo
    Pippo:
    Smart move Ebony, I think you have a successful carrier ahead of you.

    A successful carrier? You mean like the USS Nimitz?

  • cowardly man (unregistered) in reply to QJo
    QJo:
    We were maintaining an elderly FORTRAN app some years ago, which queued entries onto a print queue. All went well till our new printer software suddenly decided that all files would be printed in size order. So all the front pages came out, then all the back pages, then the report content, thereby causing a colossal manual overhead in collating the damn things, which previously had been printed envelope-perfect.

    The solution of course was to concatenate the complete report into one file before printing: front page, body, back page in that order, so that they would be directly ready once more for mailing.

    The next problem concerned how to uniquely create a report file. This was done by means of a timestamp, consisting of day, month, hour, minute, second, all in 2-digit format, concatenated into one integer.

    Suddenly, on the 22nd of October, all the print jobs failed.

    Why did they fail? I'm sure I could sift through the logic and make some pseudo code. ... but I have not the free time.

  • (cs) in reply to Anon

    So when the boss calls you into his office for a major screw up, that means you're about to ...CARRIER LOST

  • QJo (unregistered) in reply to American
    American:
    QJo:
    We were maintaining an elderly FORTRAN app some years ago, which queued entries onto a print queue. All went well till our new printer software suddenly decided that all files would be printed in size order. So all the front pages came out, then all the back pages, then the report content, thereby causing a colossal manual overhead in collating the damn things, which previously had been printed envelope-perfect.

    The solution of course was to concatenate the complete report into one file before printing: front page, body, back page in that order, so that they would be directly ready once more for mailing.

    The next problem concerned how to uniquely create a report file. This was done by means of a timestamp, consisting of day, month, hour, minute, second, all in 2-digit format, concatenated into one integer.

    Suddenly, on the 22nd of October, all the print jobs failed.

    Easy Fix: Start with the month, not the day...

    Once the appropriate facepalm moments had been indulged in, we did it properly by building the filename using a proper FORMAT command which did not rely upon the cloth-brained integer implementation put together by the perpetrator of this particular WTF.

    But you're right (and everybody else who commented), this was a particularly silly implementation.

  • QJo (unregistered) in reply to gnasher729
    gnasher729:
    John:
    Medinoc:
    At least they didn't parse the numbers as octal.
    I'd guess that their code actually tries to do that; that's why they remove the initial zero. And they only remove the first zero, because they "know" that the 2nd digit is never zero. Until management OKs some other department's request that phone "numbers" starting with "00" are to be used for some special purpose. Then more hilarity will ensue.

    Foreign phone numbers start with 00. For example, USA called from the UK starts with 001.

    ... and are more like 15 digits long (for a typical e.g. UK number from the US) rather than 10, (13 without the 00 at the start) so you're already blown out of the water.

  • ¯\(°_o)/¯ I DUNNO LOL (unregistered) in reply to American
    American:
    QJo:
    The next problem concerned how to uniquely create a report file. This was done by means of a timestamp, consisting of day, month, hour, minute, second, all in 2-digit format, concatenated into one integer.

    Suddenly, on the 22nd of October, all the print jobs failed.

    Easy Fix: Start with the month, not the day...
    TRWTF is Europeans using little-endian dates with big-endian time. ISO-8601 or GTFO.

  • faoileag (unregistered) in reply to cowardly man
    cowardly man:
    QJo:
    ...how to uniquely create a report file. This was done by means of a timestamp, consisting of day, month, hour, minute, second, all in 2-digit format, concatenated into one integer.

    Suddenly, on the 22nd of October, all the print jobs failed.

    Why did they fail?

    Because 2210124553 is larger than MAXINT for a signed 32-Bit integer?

  • (cs) in reply to faoileag
    faoileag:
    cowardly man:
    Why did they fail?
    Because 2210124553 is larger than MAXINT for a signed 32-Bit integer?

    What's even more amazing is that 2209124553 wasn't.

  • faoileag (unregistered) in reply to international WTF
    international WTF:
    What idiot would use integeres for phone numbers in the first place. Try international numbers in that field:
    Only that international numbers had not been a requirement. As the article states, this was meant to be an inhouse application for a Lonon university and all numbers were asumed to be local.

    Building international support into the phonenumber field without it being required would be something like premature generalization.

    Yeah, I know. It's still a wtf. :-)

  • chreng (unregistered)

    Duh! Use a long long!

  • European (unregistered) in reply to ¯\(°_o)/¯ I DUNNO LOL
    ¯\(°_o)/¯ I DUNNO LOL:
    American:
    QJo:
    The next problem concerned how to uniquely create a report file. This was done by means of a timestamp, consisting of day, month, hour, minute, second, all in 2-digit format, concatenated into one integer.

    Suddenly, on the 22nd of October, all the print jobs failed.

    Easy Fix: Start with the month, not the day...
    TRWTF is Europeans using little-endian dates with big-endian time. ISO-8601 or GTFO.
    But not as stupid as using middle-endian dates.

  • 123456 (unregistered) in reply to CigarDoug

    /agreed

    How come no one ever tries to change things? In real IT we have to make changes all the time, especially when something is, oh I don't know....broken.

    People, even unreasonable people who do not like change, will allow it if you can explain to them why it needs to be done. In this case, it should be a simple change to the system to fix what the original developers didn't foresee. The system is broken.

    Definitely TRWTF is Ebony and the manager just not trying.

  • Troy (unregistered) in reply to DCRoss
    DCRoss:
    faoileag:
    cowardly man:
    Why did they fail?
    Because 2210124553 is larger than MAXINT for a signed 32-Bit integer?

    What's even more amazing is that 2209124553 wasn't.

    It was September. Everyone was too busy discovering the internet to try to print.

  • Pointing and laughing across the Atlantic. (unregistered) in reply to European
    European:
    But not as stupid as using middle-endian dates.

    The funniest thing about middle endian is when Americans try and defend it... great times had by all.

  • F (unregistered) in reply to Anon
    Anon:
    Pippo:
    Smart move Ebony, I think you have a successful carrier ahead of you.

    A successful carrier? You mean like the USS Nimitz?

    Typhoid Mary, more like.

  • (cs) in reply to John
    John:
    So when is it advantageous to store strings that aren't really numbers in a numeric format? I haven't ever seen any real advantage to this. And note that it only matters to programmers, since they're the only ones that see the actual formatting. Arguments based on the feelings of non-programmers aren't really relevant to deciding what internal format to use.

    If you are very constrained for space. That said, I would not do it if I could avoid it.

    Any savings could be eaten up by more complex programming. For example, you can not print a numeric ZIP Code without having to convert it (or missing leading zeroes).

    Sincerely,

    Gene Wirchenko

  • Pointing and laughing across the Atlantic. (unregistered) in reply to F

    Little known fact...

    The USS Typhoid Mary can carry up to 90 aircraft, has 2.5 inch kevlar armour, and is armed with 24 Sea Sparrow missiles.

  • Valued Service (unregistered) in reply to Krunt
    Krunt:
    Raedwald:
    I'm reminded of some advice that I saw here sometime ago: if you would not do arithmetic with a field, do not store it as a numerical type (store it as a string).

    Which is yet another unrealistic generalisation that college graduates and evangelical DBAs like to quote without really thinking through.

    They did think it through. Finally, after failing so hard so many times. Which is why you have the generalization.

    Seriously, there is no benefit not to do this unless you're limited on memory or throughput.

  • (cs) in reply to DCRoss
    DCRoss:
    faoileag:
    cowardly man:
    Why did they fail?
    Because 2210124553 is larger than MAXINT for a signed 32-Bit integer?

    What's even more amazing is that 2209124553 wasn't.

    Maybe they used the Java constants for months?

    From java/util/Calendar.java:

        public final static int JANUARY = 0;
...
    public final static int OCTOBER = 9;
...
    public final static int DECEMBER = 11;
...
    public final static int UNDECIMBER = 12;
  • Aris (unregistered) in reply to martijntje
    martijntje:
    graybeard:
    Eh, easy solution: mobile numbers are negative, and any negative values shall be prefixed by 07.
    Ah, a graduate from WTF-U is amongst us.
    I really like that solution, it just looks brillant
  • Mason Wheeler (unregistered) in reply to evilspoons
    evilspoons:
    American:

    Easy Fix: Start with the month, not the day...

    Yeah, that makes more sense anyway. Who the heck goes "hey, let's sort data by the second most significant unit, then the most significant unit, then the third most significant unit..."

    Oh wait, I know who.

    The fine folks at IBM who developed the syntax of the SQL SELECT query, that's who.

    (Think about it. Under what logic does it make sense to put the field list at the start of the query and not the end?)

  • (cs)

    Ahhh, the beauty of SLAs.

    "If we can't fix it, we won't support it. We're forwarding all complaints to you."

  • (cs) in reply to evilspoons
    evilspoons:
    American:

    Easy Fix: Start with the month, not the day...

    Yeah, that makes more sense anyway. Who the heck goes "hey, let's sort data by the second most significant unit, then the most significant unit, then the third most significant unit..."

    Oh wait, I know who.

    Are you confusing sorting and presentation formats?

Leave a comment on “Call Me, Maybe”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article