The Daily WTF: Curious Perversions in Information Technology

2014-01-22 Reply Admin

Mason Wheeler:
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?)

I have no idea why you would want to define your outcomes before gathering data /sarcasm

2014-01-22 Reply Admin

Just to nitpick, 020 is an area code, not a local exchange. London has a lot more than one of the latter, I assure you.

ochrist · 2014-01-22 Reply Admin

Pointing and laughing across the Atlantic.:
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.

That must be American endians

2014-01-22 Reply Admin

Pointing and laughing across the Atlantic.:
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.

I've never met anyone who actually tried to defend it. Most just shrug their shoulders and walk away.

Snooder · 2014-01-22 Reply Admin

John:
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.

While I agree with you in the general, the important point to remember about that phrase is the "if you aren't doing arithmetic on it". Sometimes doing arithmetic on a number has better performance than doing string manipulation on the equivalent string.

For example, I'm guessing that the Highly Paid Consultant graduates chose to use integers to store the phone numbers because they were doing some sort of parsing of the number. Maybe to get the area code, department, building, etc. As a integer with a well defined length, it's easy to use modulus to get whatever portion of the number you want. As a string, you'd have to use some sort of substring function which is almost always worse performing. If they are doing this on older hardware and the parsing happens a lot, then storing the phone number as an integer makes sense.

The point though, is that you have to actually think about it and figure out if your use case is the general or a specific outlier.

no laughing matter · 2014-01-22 Reply Admin

Snooder:
As a integer with a well defined length, it's easy to use modulus to get whatever portion of the number you want. As a string, you'd have to use some sort of substring function which is almost always worse performing. If they are doing this on older hardware and the parsing happens a lot, then storing the phone number as an integer makes sense.

Modulo operation being more efficient than copy some bytes from one array into another? You are really trolling hard!

Number of CPU cycles for calculating IDIV on an 8086 (which includes calculating remainder): 8 bit reg 101-112 16 bit reg 165-184 8 bit mem 107-118 + EA 16 bit mem 171-190 + EA

And that is already fast, many older processors didn't have hardware support for DIV

chubertdev · 2014-01-22 Reply Admin

Snooder:
As a integer with a well defined length

Extensions, country codes, different formats for area codes, etc...definitely not a well-defined length.

2014-01-22 Reply Admin

Dan:
I've never met anyone who actually tried to defend it. Most just shrug their shoulders and walk away.

I've heard a defense for it. It goes something like

"Most of the time, the year is obvious, and so can be omitted, leaving MM-DD as the sane, sortably ordered date. Then in cases in which the year isn't obvious, it should be added to the rest of the date in a format that doesn't disrupt the ordering, so it gets tacked on to the back. This gives MM-DD-YYYY. So if you write a list of dates

2/9 5/21 8/11

And you want to add last year's January 30 to the top without rewriting the entire list, you can just add '1/30/YYYY'."

It's a mistake approximate to storing the year as two ASCII values. It works fine and saves time/space when the data only sticks around for a while and all parties involved know about the missing information (in this case, the year, in that case the prefixing of "19". When you start doing anything beyond those limitations, it's a pain in the neck.

dkf · 2014-01-22 Reply Admin

someguy:
And you want to add last year's January 30 to the top without rewriting the entire list, you can just add '1/30/YYYY'."

And then you add next year's January 17, and it sorts to the top! (If you want sorting, save yourself a whole load of pain and use ISO8601 in timezone Zulu and layer some pretty printing on top for the lusers.)

PedanticCurmudgeon · 2014-01-22 Reply Admin

Kasper:
QJo:
dba_wanna_be:
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 only appropriate +1 comment, I have yet seen.

FTFY

da Doctah · 2014-01-22 Reply Admin

123456:
/ 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.

I don't know how many times I've had to resort to:

Client: "Fix this, it doesn't work." Me: "Okay, all I have to do is change this bit here." Client: "You can't change that bit because it has to keep doing what it's always done." Me: "What it's always done? You mean not working?"

slavdude · 2014-01-22 Reply Admin

Dialing overseas from the U.S. starts with 011. So not just a problem in the U.K.

2014-01-22 Reply Admin

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

Depends where you are from. International dial-out in Australia is a 1100 prefix + country code + local number

2014-01-22 Reply Admin

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 didn't they also fail on the 22nd of January, 22nd of February, etc.?

Also, why wasn't that comment blued the first time? http://thedailywtf.com/Comments/Confessions-The-Phone-Number.aspx?pg=4#385655

Akismet says thedailywtf.com is a spam site.

2014-01-22 Reply Admin

Pointing and laughing across the Atlantic.:
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.

And has its own mobile phone company -- an uncommon carrier.

2014-01-22 Reply Admin

Norman Diamond:
QJo:
Suddenly, on the 22nd of October, all the print jobs failed.
Why didn't they also fail on the 22nd of January, 22nd of February, etc.?

Maybe, just maybe, because the new naming scheme was implemented some time in early October?

2014-01-22 Reply Admin

Norman Diamond:
QJo:
Suddenly, on the 22nd of October, all the print jobs failed.
Why didn't they also fail on the 22nd of January, 22nd of February, etc.?

Perhaps because the system had only been implemented on the 1st of October?

2014-01-22 Reply Admin

capio:
Norman Diamond:
QJo:
Suddenly, on the 22nd of October, all the print jobs failed.
Why didn't they also fail on the 22nd of January, 22nd of February, etc.?
Maybe, just maybe, because the new naming scheme was implemented some time in early October?

Wrexham:
Norman Diamond:
QJo:
Suddenly, on the 22nd of October, all the print jobs failed.
Why didn't they also fail on the 22nd of January, 22nd of February, etc.?
Perhaps because the system had only been implemented on the 1st of October?

Great minds think alike!

2014-01-22 Reply Admin

John:
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.

Yes, all those conversion between integer and string, after (in a typical scenario) you read from an ORM like Hibernate that uses reflection to populate class fields, after it has decoded a JDBC result set which was populated by the driver after it interpreted the data it read from a buffer that was filled by a socket class that had to interact with the OS level socket...

I guess it's easy to win an argument with people who have no clue how anything works.

2014-01-22 Reply Admin

Norman Diamond:
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 didn't they also fail on the 22nd of January, 22nd of February, etc.?

Also, why wasn't that comment blued the first time? http://thedailywtf.com/Comments/Confessions-The-Phone-Number.aspx?pg=4#385655

Akismet says thedailywtf.com is a spam site.

Good question, and I confess I misremember the details. I think because when we dig into it we found that the month had been formatted to as many digits as the month happened to have, so while 22nd Sept would have been 229hhmmss, ... well, you see where this goes.

2014-01-22 Reply Admin

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

Depends where you are from. International dial-out in Australia is a 1100 prefix + country code + local number

No it's not. It's 0011. Hilarity ensues with PABX systems that require you to dial a 0 for an outside line, and emergency services being 000.

coyo · 2014-01-23 Reply Admin

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

That might not be ah..extendable enough. Store half the value and indicate that the phone number is odd using the negative.

2014-01-23 Reply Admin

ochrist:
Pointing and laughing across the Atlantic.:
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.

That must be American endians

Sheesh, don't be so rude. It's "native endians".

JimM · 2014-01-23 Reply Admin

Gene Wirchenko:
John:
So when is it advantageous to store strings that aren't really numbers in a numeric format?

If you are very constrained for space.

No, everyone knows that nvarchar is the most efficient storage data type. Don't they?

I had a colleague a few years ago who approached me one day to ask what the maximum value in a particular database column was, or was ever likely to be. Expecting him to suggest using a smaller int data type (I was feeling lazy when I wrote the table definition and just plumped for plain old int ;) ), I sheepishly confirmed that they were unlikely to go over about 50, at which point he converted the column to nvarchar(2), to save space in the database.

I kid you not.

2014-01-23 Reply Admin

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.

The correct version is: store identifiers which your system does not control as strings. What is depressing is that we have known this since, at the latest, 1953. Isn't it time that programming became a profession?

Do it the purist way. Your successors will not thank you, because they'll never have to deal with problems that don't happen. By the same token, they won't curse you, either.

Zemm · 2014-01-23 Reply Admin

Josh:
International dial-out in Australia is a 1100 prefix + country code + local number

No, 1100 in Australia is "Dial before you dig" - a service that should tell you where underground telephone, electricity, gas, water, sewage, etc lines are.

Yes it's 0011 and most phone systems use 0 for "outside line" (and 0 prefix for interstate) so you could accidentally dial emergency 000. Similar in the USA where 9 is often "outside line" and 1 for long-distance, if you double up on the 1 you could accidentally dial 911.

I'd really like Australia to change the 0011 to simply 00, like most of the world, but then we'd probably have to change the emergency number to something like 112. I'd also like to remove area codes, dropping the leading 0, and have simple nationwide nine-digit numbers. But I'm not in charge of numbering.

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

And to call Russia with love you'd use 007. :)

Zemm · 2014-01-23 Reply Admin

QJo:
Good question, and I confess I misremember the details. I think because when we dig into it we found that the month had been formatted to as many digits as the month happened to have, so while 22nd Sept would have been 229hhmmss, ... well, you see where this goes.

This was my first thought when reading the post.

There would be a possible conflict between 11 January and 1 November or 11 February and 1 December. But was that number just used as an identifier?

2014-01-23 Reply Admin

Kasper:
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.

Like :-)

2014-01-23 Reply Admin

Norman Diamond:
QJo:
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 didn't they also fail on the 22nd of January, 22nd of February, etc.?

Perhaps the "workaround" had been developed sometime between the 1st of October and the 21st?

Zemm · 2014-01-23 Reply Admin

faoileag:
Norman Diamond:
QJo:
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 didn't they also fail on the 22nd of January, 22nd of February, etc.?
Perhaps the "workaround" had been developed sometime between the 1st of October and the 21st?

But 221000000, 222000000, etc are well under MAX_INT. So it couldn't have been a problem until a double digit month...

2014-01-23 Reply Admin

I ran into a similar bug a few years ago, except the issue was with a system taking in US numbers, and the problem was that most user were having their numbers turned into a random Texas number. Of course, it turned out that a bit of logic was putting it through an integer transform that cut it down to the maximum possible value if it exceeded - and (214) 748 3648 is a valid Texas phone number...

2014-01-23 Reply Admin

Developers that do shit like this should be shot.

2014-01-23 Reply Admin

Zemm:
QJo:
Good question, and I confess I misremember the details. I think because when we dig into it we found that the month had been formatted to as many digits as the month happened to have, so while 22nd Sept would have been 229hhmmss, ... well, you see where this goes.

This was my first thought when reading the post.

There would be a possible conflict between 11 January and 1 November or 11 February and 1 December. But was that number just used as an identifier?

The files would not be expected to hang around for that long. They are temporary files used to hold reports (usually monthly) which would be expected, once printed, to be mailed to the customer. The directory would have been cleared by end of week at latest.

2014-01-23 Reply Admin

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.

Not if 22 September was stored as 229124553, not 2209124553 (you assumed the leading zero for 09).

2014-01-23 Reply Admin

ochrist:
Pointing and laughing across the Atlantic.:
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.

That must be American endians

1 little, 2 little, 3 little endians...

2014-01-23 Reply Admin

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 practice predates computers, and has nothing to do with significant units. If the way you say the date out loud is "October 15th, 2013" then it makes sense to write it as 10/15/13. 15/10/13 only makes sense if you were raised to say "15 October 2013".

There, someone defended it.

2014-01-23 Reply Admin

They do this right in Japan, I believe; big-endian:

2014-01-23 17:28:07 1234

(With the added advantage that lexical order is date order.)

2014-01-23 Reply Admin

Snooder:
Maybe to get the area code, department, building, etc. As a integer with a well defined length, it's easy to use modulus to get whatever portion of the number you want. As a string, you'd have to use some sort of substring function which is almost always worse performing. If they are doing this on older hardware and the parsing happens a lot, then storing the phone number as an integer makes sense.

The fact that you're describing an integer as having a "well defined length" indicates that you're making the elementary mistake that inspired the saying: you're thinking of integers in terms of the way they are presented as text in base-ten. Integers do not have lengths. Strings have lengths.

Storing non-numeric data in a numeric format does not make sense, period. There is no counter-argument to this that doesn't involve some bizarre external artificial restrictions.

Just because it's non-numeric doesn't mean it's a string, though. What you're describing is neither textual nor numeric. It's a structure with multiple components: area code, department, building. If we want to process those individually, then we store them in such a way that they can be accessed individually.

2014-01-23 Reply Admin

The 00 is the international access code and the 1 is the country code for US. When you call from the UK, the US uses 011 and 44 is the country code for the UK.

The convention is to use the + for the international access code, then the country code and then the number without the leading 0.

2014-01-23 Reply Admin

Paul:
They do this right in Japan, I believe; big-endian:
2014-01-23 17:28:07 1234

(With the added advantage that lexical order is date order.)

Yes. Also China does it the same way, and SI does it the same way, and in recent years Canada and the US have started copying that in some places. As a matter of fact, look at the timestamp that this site put on your comment.

2014-01-23 Reply Admin

Norman Diamond:
Also, why wasn't that comment blued the first time? http://thedailywtf.com/Comments/Confessions-The-Phone-Number.aspx?pg=4#385655
Akismet says thedailywtf.com is a spam site.

Hey wait, Akismet is right! With all those advertisements for stolen credit cards, fake passports, etc., thedailywtf.com is a spam site.

2014-01-24 Reply Admin

European:
¯\(°_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.

Eh, you folk use middle-endian datetimes. dd-mm-yyyy hh:mm:ss. If you're not going to be consistent, fuck off and quit ragging on people for being inconsistent.

2014-01-24 Reply Admin

Is this the same Ebony from My Immortal? I had wondered where she'd ended up...

2014-01-25 Reply Admin

CigarDoug:
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.

Not if 22 September was stored as 229124553, not 2209124553 (you assumed the leading zero for 09).

Right. The other option is that they only implemented this change in October.

2014-01-28 Reply Admin

So dumb and naïve to store a phone number as an integer.

"A phone number is a number, right? So we should use a numeric type to store it!".

AndyCanfield · 2014-01-29 Reply Admin

I live in Thailand. Most of the time, on the Internet, I enter my phone number starting with "+66", which is the Thailand country code. Sometimes the GUI won't take the plus sign.

2014-01-29 Reply Admin

minim:
Just to nitpick, 020 is an area code, not a local exchange.

It could be worse; many UK residents still believe in 0207 and 0208 area codes, which have never existed.

2014-01-29 Reply Admin

AndyCanfield:
I live in Thailand. Most of the time, on the Internet, I enter my phone number starting with "+66", which is the Thailand country code. Sometimes the GUI won't take the plus sign.

None of my phones have a + key, so why should the GUI accept it?

2014-02-02 Reply Admin

Norman Diamond:
Paul:
They do this right in Japan, I believe; big-endian:
2014-01-23 17:28:07 1234

(With the added advantage that lexical order is date order.)
Yes. Also China does it the same way, and SI does it the same way, and in recent years Canada and the US have started copying that in some places. As a matter of fact, look at the timestamp that this site put on your comment.

ISO8601, the standard date/time format.

2014-02-03 Reply Admin

Ebony was clearly not destined to become a Highly Paid Consultant. Else she'd have simply explained to management that in order for the application to support mobile numbers, the university would need to upgrade it to the 64-bit version.

Call Me, Maybe

Leave a comment on “Call Me, Maybe”