How to handle dates _properly_. [modified]
-
First, you use a varchar(20) default '' to store a six char date in the form yymmdd. Users have the luxury of an extra fourteen chars to add willy nilly romantic annotations to the date. Savvy data entry clerks may even squeeze a well formed XHTML tag in there. Then, when the huns appear over the next control-break horizon, and you need the real DateTime you promised them, you divide and conquer. A bunch of little two character numbers quickly evaporate into two character numbers. Except the year pair, '09'. In the shocking assault on decency everywhere, teh geinus grugru of date parsing expertly recognised that the '09' needed '20'. Why waste two innocent zeros and add '2000', when you can add '20', as in string conctratingation, but hey, strings are for physicists and yoyos, so lets just add 20. In the following horrific, true life example of unprecedented savagery, our valiant knight takes a string value for
detailLastDate; of '090722' and with a wave of a hanky and quickly stuffing a rabbit into a hat for distraction, presents The Date Parsing canon (emphasis mine):DateTime time2 = new DateTime(int.Parse(20 + detailLastDate.Substring(0, 2)), int.Parse(detailLastDate.Substring(2, 2)), int.Parse(detailLastDate.Substring(4, 2)));
Isn't it wonderful how he can just add the integer 20 to the substring '09', and get a year value of 2009? I am forever in awe.
Last modified: 9hrs 10mins after originally posted --
-
First, you use a varchar(20) default '' to store a six char date in the form yymmdd. Users have the luxury of an extra fourteen chars to add willy nilly romantic annotations to the date. Savvy data entry clerks may even squeeze a well formed XHTML tag in there. Then, when the huns appear over the next control-break horizon, and you need the real DateTime you promised them, you divide and conquer. A bunch of little two character numbers quickly evaporate into two character numbers. Except the year pair, '09'. In the shocking assault on decency everywhere, teh geinus grugru of date parsing expertly recognised that the '09' needed '20'. Why waste two innocent zeros and add '2000', when you can add '20', as in string conctratingation, but hey, strings are for physicists and yoyos, so lets just add 20. In the following horrific, true life example of unprecedented savagery, our valiant knight takes a string value for
detailLastDate; of '090722' and with a wave of a hanky and quickly stuffing a rabbit into a hat for distraction, presents The Date Parsing canon (emphasis mine):DateTime time2 = new DateTime(int.Parse(20 + detailLastDate.Substring(0, 2)), int.Parse(detailLastDate.Substring(2, 2)), int.Parse(detailLastDate.Substring(4, 2)));
Isn't it wonderful how he can just add the integer 20 to the substring '09', and get a year value of 2009? I am forever in awe.
Last modified: 9hrs 10mins after originally posted --
Not sure about that, but I can feel some kind of irony in this post... :laugh:
-
First, you use a varchar(20) default '' to store a six char date in the form yymmdd. Users have the luxury of an extra fourteen chars to add willy nilly romantic annotations to the date. Savvy data entry clerks may even squeeze a well formed XHTML tag in there. Then, when the huns appear over the next control-break horizon, and you need the real DateTime you promised them, you divide and conquer. A bunch of little two character numbers quickly evaporate into two character numbers. Except the year pair, '09'. In the shocking assault on decency everywhere, teh geinus grugru of date parsing expertly recognised that the '09' needed '20'. Why waste two innocent zeros and add '2000', when you can add '20', as in string conctratingation, but hey, strings are for physicists and yoyos, so lets just add 20. In the following horrific, true life example of unprecedented savagery, our valiant knight takes a string value for
detailLastDate; of '090722' and with a wave of a hanky and quickly stuffing a rabbit into a hat for distraction, presents The Date Parsing canon (emphasis mine):DateTime time2 = new DateTime(int.Parse(20 + detailLastDate.Substring(0, 2)), int.Parse(detailLastDate.Substring(2, 2)), int.Parse(detailLastDate.Substring(4, 2)));
Isn't it wonderful how he can just add the integer 20 to the substring '09', and get a year value of 2009? I am forever in awe.
Last modified: 9hrs 10mins after originally posted --
I suddenly feel lucky (see below)
-
First, you use a varchar(20) default '' to store a six char date in the form yymmdd. Users have the luxury of an extra fourteen chars to add willy nilly romantic annotations to the date. Savvy data entry clerks may even squeeze a well formed XHTML tag in there. Then, when the huns appear over the next control-break horizon, and you need the real DateTime you promised them, you divide and conquer. A bunch of little two character numbers quickly evaporate into two character numbers. Except the year pair, '09'. In the shocking assault on decency everywhere, teh geinus grugru of date parsing expertly recognised that the '09' needed '20'. Why waste two innocent zeros and add '2000', when you can add '20', as in string conctratingation, but hey, strings are for physicists and yoyos, so lets just add 20. In the following horrific, true life example of unprecedented savagery, our valiant knight takes a string value for
detailLastDate; of '090722' and with a wave of a hanky and quickly stuffing a rabbit into a hat for distraction, presents The Date Parsing canon (emphasis mine):DateTime time2 = new DateTime(int.Parse(20 + detailLastDate.Substring(0, 2)), int.Parse(detailLastDate.Substring(2, 2)), int.Parse(detailLastDate.Substring(4, 2)));
Isn't it wonderful how he can just add the integer 20 to the substring '09', and get a year value of 2009? I am forever in awe.
Last modified: 9hrs 10mins after originally posted --
Isn't it wonderful how he can just add the integer 20 to the substring '09', and get a year value of 2009? I am forever in awe. Whether or not it was reasonable for programmers in the 80's and 90's to figure their code would be obsolete before the year 2000, I see no reason to believe that any code written today will not be obsolete before the year 2100. At least the programmer deserves credit for not trying to add punctuation to convert the string to mm-dd-yy form and doing an unadorned parse on that (which would succeed or fail depending upon locale).
-
Isn't it wonderful how he can just add the integer 20 to the substring '09', and get a year value of 2009? I am forever in awe. Whether or not it was reasonable for programmers in the 80's and 90's to figure their code would be obsolete before the year 2000, I see no reason to believe that any code written today will not be obsolete before the year 2100. At least the programmer deserves credit for not trying to add punctuation to convert the string to mm-dd-yy form and doing an unadorned parse on that (which would succeed or fail depending upon locale).
supercat9 wrote:
I see no reason to believe that any code written today will not be obsolete before the year 2100.
I strongly disagree. IF y2k and the last decade have taught us anything it's that crufty old code doesn't die, it just gets wrapped in interface translation layers to feed newer systems.
The European Way of War: Blow your own continent up. The American Way of War: Go over and help them.
-
First, you use a varchar(20) default '' to store a six char date in the form yymmdd. Users have the luxury of an extra fourteen chars to add willy nilly romantic annotations to the date. Savvy data entry clerks may even squeeze a well formed XHTML tag in there. Then, when the huns appear over the next control-break horizon, and you need the real DateTime you promised them, you divide and conquer. A bunch of little two character numbers quickly evaporate into two character numbers. Except the year pair, '09'. In the shocking assault on decency everywhere, teh geinus grugru of date parsing expertly recognised that the '09' needed '20'. Why waste two innocent zeros and add '2000', when you can add '20', as in string conctratingation, but hey, strings are for physicists and yoyos, so lets just add 20. In the following horrific, true life example of unprecedented savagery, our valiant knight takes a string value for
detailLastDate; of '090722' and with a wave of a hanky and quickly stuffing a rabbit into a hat for distraction, presents The Date Parsing canon (emphasis mine):DateTime time2 = new DateTime(int.Parse(20 + detailLastDate.Substring(0, 2)), int.Parse(detailLastDate.Substring(2, 2)), int.Parse(detailLastDate.Substring(4, 2)));
Isn't it wonderful how he can just add the integer 20 to the substring '09', and get a year value of 2009? I am forever in awe.
Last modified: 9hrs 10mins after originally posted --
So, was this a replacement for an older program that used "19 +"?
-
supercat9 wrote:
I see no reason to believe that any code written today will not be obsolete before the year 2100.
I strongly disagree. IF y2k and the last decade have taught us anything it's that crufty old code doesn't die, it just gets wrapped in interface translation layers to feed newer systems.
The European Way of War: Blow your own continent up. The American Way of War: Go over and help them.
I strongly disagree. IF y2k and the last decade have taught us anything it's that crufty old code doesn't die, it just gets wrapped in interface translation layers to feed newer systems. Code can be around for awhile, certainly, but from a user I/O perspective I don't see much point to using four-digit years for most purposes (from an internal-storage perspective, storing a year as two digits is generally silly with or without century-wrap issues). If an application is only going to deal with dates in the near future or recent past, there's no reason to require users to waste keystrokes typing a leading "20", nor is there any reason to waste space printing or displaying a "20" in front of years on paper or screen. If, seventy years from now, a printed document bears a date of 01-01-76, it will almost certainly be obvious whether the document was produced in the 1970's or 2070's. Even if there were no further improvements in printing technologies, the earliest possible ambiguities for documents printed on quality paper wouldn't occur until 2090 or so; even then, it should be obvious which documents were printed in 1990 and which ones were printed in 2090.
-
First, you use a varchar(20) default '' to store a six char date in the form yymmdd. Users have the luxury of an extra fourteen chars to add willy nilly romantic annotations to the date. Savvy data entry clerks may even squeeze a well formed XHTML tag in there. Then, when the huns appear over the next control-break horizon, and you need the real DateTime you promised them, you divide and conquer. A bunch of little two character numbers quickly evaporate into two character numbers. Except the year pair, '09'. In the shocking assault on decency everywhere, teh geinus grugru of date parsing expertly recognised that the '09' needed '20'. Why waste two innocent zeros and add '2000', when you can add '20', as in string conctratingation, but hey, strings are for physicists and yoyos, so lets just add 20. In the following horrific, true life example of unprecedented savagery, our valiant knight takes a string value for
detailLastDate; of '090722' and with a wave of a hanky and quickly stuffing a rabbit into a hat for distraction, presents The Date Parsing canon (emphasis mine):DateTime time2 = new DateTime(int.Parse(20 + detailLastDate.Substring(0, 2)), int.Parse(detailLastDate.Substring(2, 2)), int.Parse(detailLastDate.Substring(4, 2)));
Isn't it wonderful how he can just add the integer 20 to the substring '09', and get a year value of 2009? I am forever in awe.
Last modified: 9hrs 10mins after originally posted --
varchar(20), you are lucky... somebody who's name i will not mention, there it's my only "programming" colleague, is coming from VB6 and now in .Net all data types are still variant(in her head). Adding numbers to strings is standard... Type Casting? What is that? Turning on option strict results in hundreds of errors , in one project with one source file, of 3000 lines... and tables, don't ask ... today my heart stopped a moment with this... CREATE TABLE `tkolkinfo` ( `tkolkIK` int(11) NOT NULL auto_increment, `tKolkClientId` varchar(100) NOT NULL default '', `tKolkTimestampBerichtOpmaak` varchar(100) NOT NULL default '', `tKolkTimestampDateKolkDone` varchar(100) NOT NULL default '', `tKolkTimestampHourKolkDone` varchar(100) NOT NULL default '', `tKolkTimestampDateTimeKolkDone` varchar(100) NOT NULL default '', But at least in the company where i work next to .Net there is windev, helping me to forget all the IT horror and dream away on a beach with a beautifull girl: http://www.pcsoft-windev-webdev.com/WD14brochure.pdf[^] (this was sarcasm for the ones who didn't notice...)
It feels good to learn and achieve
modified on Monday, August 24, 2009 10:47 PM