- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Ermahgerd! Tern egein!
Admin
I'm not convinced that the result in StDt will be identical to FromDt. Specifically, StDt will have no leading zeros in the first two components (whatever they may be), so if your locale's short date format specifies 2-digit day and month the result will differ.
Remy: Look carefully- the line where mth gets populated may convert to an int, but the int value is only used for the comparison. The original string (complete with leading zeroes) is used to populate mth.
Admin
Well, it does look as though it does something ... unless I am misreading this, it converts a date in the form "04/01/2018" into a date in the form "4/1/2018". Or maybe it doesn't. I don't know. I'm not sure how Stdt comes in. It may have already arrived in the form "4/1/2018". Maybe the programmer was not sure whether it arrived in the form "04/01/2018" or "4/1/2018" and just wanted to make sure it was in the form "4/1/2018".
Or maybe he was paid by LoC and wanted to add a few obfuscatory lines which would not actually do anything, with a view towards handling the lucrative contract to internationalise it later on down the line of development.
Admin
Nope... while it does convert day and month to integers, the values actually concatenated are the original strings, so it won't strip the leading zeroes. It's just a complicated way of splitting the string by '/', then joining it by '/' again.
Admin
You should see code dealing with calculating historical date and times for different time zones including daylight saving time over different years. I.e. something happened 1987-07-12 12:00 in Amsterdam. What was the time then in Riyad? The standard Java libraries was not up to that task and joda time also had its issues on this tema. DST is not fixed over time and does not need to be on whole (or 1/2) hours. Java stubborn always convert to local time.
Admin
Not only DST is not fixed, sometimes complete time zones are changed. In fact, almost every year there's some change in some country. I don't do Java, but I'd be quite surprised (and disappointed) if it couldn't handle that. Even good old Unix timezones can do that -- yes, they do convert to/from local time, but what is local can be changed anytime. I just tried this on the Linux command line (a C program should give the same results).
TZ=Asia/Riyadh date +%FT%T -d@
TZ=Europe/Amsterdam date -d 1987-07-12T12:00 +%s
1987-07-12T13:00:00Compare:
TZ=Asia/Riyadh date +%FT%T -d@
TZ=Europe/Amsterdam date -d 1972-07-12T12:00 +%s
1972-07-12T14:00:00Or for non full/half hours:
TZ=Asia/Kathmandu date +%FT%T -d@
TZ=Europe/Amsterdam date -d 1987-07-12T12:00 +%s
1987-07-12T15:45:00Admin
"Assuming a US-like locale" <- TRWTF
Okay, I get that it's appropriate given the provided code, but this is a very bad attitude in the general case.
And the secondary WTF is, as always, US dates.
Admin
I've seen a lot worse than this. I remember a while ago seeing hundreds of lines of things mapping months to and thro. It didn't work properly either doing all kinds of weird things getting confused with ISO/business standards for what constitutes a week/month/year boundary. To exploit weird overflow quirks (wasn't necessary) months had some issue. I can't remember if they started from 2 or started from 0 but never had a month 1!
One of the worst is a lot simpler than this though. I really had when people use some magic all powerful string_to_date function, especially with potentially arbitrary input, especially with genuinely arbitrary input (if it has date in the name just assume it can be magically converted into a date by a magic function with no issues).
Admin
This is downright disgusting. I'm pretty sure this is a wonderful example of the toxic "change as little characters as necessary to do the job" mentality.
This probably started its life as an incredibly silly way to pad zeroes on day/month < 10 by someone who had no clue about ToString() formatting, with the success part of the ternary written as "0" + arFromDate[0]. Actually, something looking like this snippet may even have been unavoidable if the goal was to always pad to 2 digits but keep the day/month order of the locale. Given its general quality, the "mth" variable and the reliance on "/" as the separator, I doubt it - the whole thing should probably have been written as stDtTime.ToString("MM/dd/yyyy") to start with.
Then the padding had to be removed (that's stDtTime.ToString("M/d/yyyy") for you, or indeed stDtTime.ToShortDateString()) and the culprit of this used the laziest possible code change, rendering 1)the ternaries absurd, and thus 2)the whole thing useless : we split with "/", and we join the same strings in the same order with "/". Therefore Stdt will always contain what was in FromDt right at the start regardless of the locale.
Bonus point for the terrible variable naming, from the shortened "month" as if that was too long to type, along with the ambiguous "date" for "day", the use of both "FromDt" and "FromDate" (are StDt and FromDate both used anyway ?)
Admin
The US format of dates makes no sense whatsoever. I've seen arguments saying its because they used to write the month in full (e.g. December 15th 2017) they just converted that to the numbers. Well that's just plain foolish... the same ingredients are used in pancakes and in Yorkshire puddings but I dare an Yank to come here and call our puddings a pancake. It's a different format - like dates
Admin
Out of curiosity, which would you be less surprised to find dates in? A pancake or a Yorkshire pudding?
Admin
Last time I had a date out for pancakes it tried to turn into a burger joint. Didn't make much more sense than that code. I'd try taking my wife out for a Yorkshire pudding but I'm afraid she might call it something much worse than a pancake.
Admin
I think a far more likely explanation is that, at one point, this code was written to add leading zeroes... the ternary used to be: int(x) < 10 ? "0" + x : x, and the code would convert strings like "1/2/93" to "01/02/93".
But then someone decided that they didn't want those leading zeroes any more... so rather than remove the block of code entirely, they just removed the part that adds the zeroes. Making the whole thing an expensive no-op.
Admin
All of that is unnecessary. Why convert a date to a string, then split it on "/" and reassemble that array into another string?
OTOH, why copy code blindly? But people do it.
Admin
intestingly, the date format doesn't matter (US or non-US) because it's just disassembling a string and reassembling it in the same order. The variable names (mth, date) imply that it's a US date format, but it's just string manipulation in the end. It would work equally well with any string with at least two / in it. I do love those ternaries. Only someone who doesn't know what a ternary is could possibly have written them.
Admin
I would be less surprised to find dates in "pancakes". In Yorkshire "pancakes" are crepes, and American "pancakes" live on the desert menu; it's more common to add dates to a sweet dish than to a savory dish. Same is true in England and the rest of Britain
Admin
I think the ternary was probably more likely originally something like: string mth = Convert.ToInt32(varFromDate[0]) < 10 ? '0' + varFromDate[0] : varFromDate[0];
until they realized they ended up with 004/001/1978, so they got rid of the "'0' +"
Admin
Anyone generating or representing dates in anything other than ISO 8601, the international date notation that was standardized in 1988, is fundamentally not competent to work with modern computer systems.
No person capable of safely operating a fork and spoon is too stupid to read an ISO 8601 date, even if they have never seen the format before.
I'm American. Stupid American Date Format is stupid, and defending it is even stupider. Don't be stupid.
Admin
If you don't assume US-ian locale, then the code will inevitably (reliably) switch month-day around irregardless. ;)
Admin
American date format is indeed stupid, but it is marginally superior to also-stupid European date format because it more closely resembles ISO format.
Admin
I think a better explanation would be that they were either looking to pad or remove padding from the two digit day and month portions - thus the check for less than 10. At some point they either didn't finish the code, or it was modified in place to "fix" it without any real thought into the right way to fix it. I vote for the second option.
Admin
"OTOH, why copy code blindly?" Cargo cult programming, if I may state the obvious.
Admin
"If you don't assume US-ian locale, then the code will inevitably (reliably) switch month-day around irregardless. ;) "
Actually, it doesn't flop anything around. The variable may be named for month but the value in the 0 position is placed first no matter what.
Admin
The best thing when in a USA type locale is to use a month abbreviation (Three letters!), then there is no confusion. We here in the USA write it that way because beginning thoughts with a number just doesn't look right. Writing out word for a month (July 4th, 1776) looks much better.
Besides that was the way I was taught in grade school (many many (700+) moons ago!).
Admin
TRWTF is the missing line
[pre]string year = Convert.ToInt32(varFromDate[2]) < 10 ? varFromDate[2] : varFromDate[2];[/pre]
Admin
If your YEAR is less than 10, yet stored in US date format ... you're doing something really wrong.
Admin
The only reason this code isn't just a straight copy of the input value is because it trims everything from the third
/
onwards while adding the ability to blow up on various forms of bad input. Which is Dumb As Hell™…Admin
Really? Don't you have any concerns for consistency? Doesn't it stick into your eyes if date and mth are checked for being less than 10 and year is not?
Admin
I've run across that idea before, and even had it waved at me by teachers, and I'm in general inclined to reject it in the case of large (when written in words) numbers. The circumlocutions necessary to avoid beginning a written sentence with a number are often ugly, and writing out "742,365" in words isn't any less ugly. Furthermore, it doesn't matter whether that's Brito-American notation for "seven hundred [and] forty two thousand three hundred [and] sixty five" or Continental-European notation for "seven hundred and forty two point three six five". Both are more obnoxiously ugly at the beginning of a sentence (or anywhere else) than the digits.
Admin
I agree with Jeremy, this was for padding the numbers with zeros. I bet the originally the coder had the zeros added to the string and ended up with results like "007/007/2018". So our intrepid non-hero removed the "0"+ from the ternaries but left the ternaries because that is how those type of people roll. In fact, I bet the whole necessary parse and recombine was to pad the numbers with zeros but was left in.
Admin
Oh man, that cracked me up for some unfathomable reason. But if I had a date, I'd probably rather she wasn't so small as to fit in either.
Admin
Depends: Do crèpes count as pancakes?
Admin
Tim writes: ““American date format is indeed stupid, but it is marginally superior to also-stupid European date format because it more closely resembles ISO format.””
What is “European date format”??? There are probably almost as many national date formats as nations in Europe.
What “more closely resembles ISO format” — US or “European” date format? (The antecedent for “it” is unclear.)
Assuming US is meant: Nope. The Swedish standard date format IS the ISO standard. (Yes, probably that way around; ISO got it from Sweden, I think.)
Admin
TRWTF is that you don't need to check if a one- or two-digit number — the month- or day-part of a date — is less than ten or not, in order to reliably (zero-)pad it to exactly two characters:
twodigit = right(concat('0', numberstring), 2);
Or:
twodigit = right(concat('0', inttostr(number)), 2);