I had the following date string from a data dump file 11-APR-07, without looking at the Coldfusion documentation I pass the string to lsParseDateTime() and dump the output to see if it parses the string correctly, which results in {ts '2007-04-11 00:00:00'}.
Great it worked! So I move on to writing my test case (yes, yes I know it should have been the other way around).
So I write a few tests to give different date stings in the dump format and then compare them against Coldfusion objects. All of them fail.
I dig deeper, dumping the dates and get the following:
- strDate:
- 11-APR-07
- expectedDate:
- {ts ‘2007-04-11 00:00:00’}
- actualDate:
- {ts ‘2007-04-11 00:00:00’}
- dateCompare( expectedDate, actualDate, ‘D’ ):
- 1
That’s strange the string representations of the dates sure do look the same. So I change the dump to dump the values from the date object (the day, month, year values) and get the following:
- strDate:
- 11-APR-07
- expectedDate:
- {ts ‘2007-04-11 00:00:00’} – day: 11 month: 4 year: 2007
- actualDate:
- {ts ‘2007-04-11 00:00:00’} – day: 11 month: 4 year: 7
- dateCompare( expectedDate, actualDate, ‘D’ ):
- 1
Ok, now I see - it’s seeing the year from the date string as 07, that’s fair enough, but why is the string representation showing 2007.
With a bit more digging (trying to create random date objects) it appears that before the year 100 Coldfusion doesn’t actually create a date object with the year you asked for but instead guesses you meant either 20xx or 19xx with the cross-over point being 30. Any date objects created with a year of 1-29 will return 20xx and any between 30-99 will return 19xx, any other positive integer will return the provided year (negative integers do something weird).
At least I’m not trying to write something that will need to handle years older than the year 100, but there go my plans for the killer web application to manage museum artefacts.
Note: This is where someone points out the CF documentation (on that hideously slow reference site) which says exactly what I discovered (but in a more concise and articulate form).