Date formatting

[zaza]

A strange problem, this.

If I run the following:

Msgbox cdate("15 Aug 2009")

in an application on my dev PC, I return a messagebox showing the correct date, 15/08/09.
On a particular different PC, however, this returns a .Net error "Could not cast string to type..." etc.

On the other hand, if I run this:

Dim mystr As String
Dim mystrarr() As String

mystr = "15/08/2009"
mystrarr = Split(mystr, "/")

Dim mydate As New Date(mystrarr(2), mystrarr(1), mystrarr(0))

MsgBox(Format(mydate, "dd/MM/yy"))

then I return the correct result 15/08/09 on my PC, but 0/15/09 on the other.

If I change the last Format line, however, to read "dd-MMM-yy", then it returns the correct 15-Aug-09 on BOTH PCs.

It looks like it might be something related to the international setttings, American vs UK format for example, which is getting it confused, but these are both exactly the same. They have the same versions of the framework installed.

Is there any different date/time formatting within the .Net framework? I would have expected it to use the local Windows settings. Any other theories as to why the date cast would crash and the formatting doesn't necessarily work properly with the month?

[jmcilhinney]

Making assumptions about formatting is always risky. CDate can only convert Strings to Dates using formats that the system understands, which may vary from system to system. You need to make a decision whether you want to accept the system defaults, in which case it's up to the user to ensure that they enter data in an acceptable format for their system, or else you need to decide on a specific format. If you choose the latter then you should use Date.ParseExact to specify the exact format you expect. As always, you should write your code defensively and handle any invalid data gracefully.

[zaza]

Agreed. However, seems very unlikely to me that any PC would fail to understand "dd MMM yy", especially a standard-build company PC, and especially when it works on one but not another.
in this case, it was actually being pulled in as part of a string from another system in a specified format, and I was simply turning it into a date to store in a date variable.

Woe betide those who think they can get away without needing exception-catching in a simple 3-line date-conversion proc which always has a standard-format input.

[jmcilhinney]

However, seems very unlikely to me that any PC would fail to understand "dd MMM yy"

Obviously it's more likely than you thought. There must be something different about those systems, otherwise they wouldn't behave differently. You simply can't afford to assume when it comes to date formats.