Date literal bigotry

re: Date literal bigotry

bill — Fri, 09 Jul 2004 06:09:00 GMT

Maybe something like VFP has: {^yyyymmdd} translates to the currently specified date format in the application.

re: Date literal bigotry

bill — Fri, 09 Jul 2004 03:56:00 GMT

Hey Greg,

Yeh, IsDate does have some wierd behaviour. It is localized, but it also assumes that if a date has the form of x/y/z then if:
(x > 12 AndAlso y <= 12) OrElse (y > 12 AndAlso x <=12)
then it's potentially a date.
That is, if you enter in 12/30/2004 it will be interpreted as 30 Dec, 2004 where ever you are. CDate does the same.

The good news is in Whidbey, the DateTime Structure has a TryParse method, so I would recommend using that ;) Tat will also let you control which culture is used.

re: Date literal bigotry

bill — Fri, 09 Jul 2004 01:35:00 GMT

Hi Bill,

<resisting urge to make big date processing whinge>

While they're at it, they need to take a long hard look at functions like IsDate(). Either 27/12/04 is a date or 12/27/04 is a date. They're not both dates. I came across someone the other day who'd loaded 60 million rows into a database table, thought they were in US format, they were in Oz format. DTS (which uses the VBA functions) just loaded the lot without a whinge. Bit of a pity that 2/3 of them had the month and day reversed though. Bigger pity that it was only noticed 3 days into production when people started saying "that's not when that happened". Try to fix it then after days of real production...

Compare that to an error at row 3 of the load. I'll take the latter every time.

</resisting urge to make big date processing whinge>

Regards,

Greg

U.S.-centric dates and localized languages

TrackBack — Thu, 08 Jul 2004 22:37:00 GMT

Je ne parle pas Francais.