d.value = #30/6/2005# makes error Date Constance is not valid

  • Thread starter Thread starter Warren Porter
  • Start date Start date
W

Warren Porter

why can't I do this in visual studio.net with vb (v.7.1, enterprise)?

dim d as DateTimePicker
d.value = #30/6/2005#

error is Date constant is not valid

I notice that #6/30/2005# does work

Everything else in my system is set to d/m/yyyy. So why are these
different?
and I how to I get it understanding dates

(as you might have guessed, I have my dates not the US way but the
rest-of-the-world way)
 
Warren Porter said:
why can't I do this in visual studio.net with vb (v.7.1, enterprise)?

dim d as DateTimePicker
d.value = #30/6/2005#

error is Date constant is not valid

I notice that #6/30/2005# does work

Everything else in my system is set to d/m/yyyy. So why are these
different?
and I how to I get it understanding dates

(as you might have guessed, I have my dates not the US way but the
rest-of-the-world way)
Click to expand...

Not according to the International Organization for Standardization (ISO)
http://www.iso.ch/iso/en/prods-services/popstds/datesandtime.html


And from the help file:

Date variables are stored as IEEE 64-bit (8-byte) integers that represent
dates ranging from January 1 of the year 1 through December 31 of the year
9999, and times from 0:00:00 (midnight) through 11:59:59 PM.

Date values must be enclosed within number signs (#) and be in the format
M/d/yyyy, for example #5/31/1993#. If you convert a Date value to the String
type, the date is rendered according to the short date format recognized by
your computer, and the time is rendered according to the time format (either
12-hour or 24-hour) in effect on your computer.

The equivalent .NET data type is System.DateTime.
 
Exactly. Good job looking that one up (I knew that #dates# were a standard,
but I forgot which organization did it).

Date formats in input/output is one thing (and most certainly should be
displayed/parsed based on the current culture), but source code is ENTIRELY
another.

If date constants in a progamming language used the current culture, code
would not be portable from one machine to another.

Same goes for language:

Imagine if the .NET framework itself were different for each language.
You'd have "DateTime.Now" in English, and "FechaTiempo.Ahora" in Spanish.
What a mess!

Although I'm somewhat shocked that the American standard for dates was
chosen instead of the "rest-of-the-world" way. I dislike both, to be
honest. I prefer YYYY-MM-DD, and I'm glad to see it being used more often in
data (ie XML).

Matthew W. Jackson
 
Matthew W. Jackson said:
Exactly. Good job looking that one up (I knew that #dates# were a standard,
but I forgot which organization did it).
Click to expand...

The #dates# bit isn't a standard - it's not mentioned on that ISO page.
The only things on the ISO page are things like YYYY-MM-DD, ISO 8601.

#m/d/yyyy# is only specified by the Visual Basic help, as far as I can
see.
 
Should have read the page myself (it was late).

Now that I think about it, the XML specs say that their dates are based on
the ISO standard. And upon further inspection, YYYY-MM-DD is in fact ISO's
standard.

I was under the impression that #m/d/yyyy# was used elsewhere, but I think
I've only seen it used in VB and Access (which is still VB).

I suppose I should (in the future) wait until daylight to discuss such
matters.

Matthew W. Jackson
 
Back
Top