Strange date

But since this is a network program, everybody will have different settings. So I wish to standardize the date regardless of the system date format.

Thanks

shers,while storing a date in a db,for example,it's preferable to store the date in the short-date format(ex. - 20/apr/06) & then when you retrieve it you know exactly what it is - as opposed to wondering whether it's in the American or English format.
By default the Windows environment interprets a date in the numeric format(for ex. - 11/09/06) as the American format.Therefore,if at all you want to store date in the numeric format & if you're prefer the English format then you must store the date(in your application) by exchanging the places of the day & month(for ex. - from 11/09/06(English) to 09/11/06(American)).Now,when you retrieve the same & want to display it in the English format repeat the same process - exchanging the places of the day & month.
In your ex.,the date "20-09-04 " is interpreted as American - but invalid!Because 20 doesn't represent any month.Therefore,it gets interpreted by the system as a year.And you get the result - 9/4/2020.

...you should not store dates as strings in your database....
absolutely! even better, store them in UT (universal time) so they are region-independent, in case the same database is used in more than one time zone

Marco

softraj: My point is that if you store the date in the database as a date rather than as a string, you don't HAVE to decipher anything. Consider the following pseudo-code. If we store date values as strings, we must:

' Get date input from user
' Determine whether user entered date in U.S. or European format
' Convert date to dd-mmm-yyyy format
' Store in database

Now it's time to retrieve the date and display it to the user:

' Retrieve date from database; it is a string in dd-mmm-yyyy format
' Determine whether user is American or European
' Parse string into day, month, year values
' Rearrange values into user's preferred format

If we store dates as dates instead of strings, we can do this:

' Get date input from user
' Assign input to Date-type variable; assignment automatically parses input based on user's regional settings and correctly determines year, month and day values
' Insert date value into database

To display:

' Retrieve date value from database
' Use Format function (VB has one built in) to format date according to user's regional settings

See how much less work you have to do in the latter case?

sorry softraj but I did not follow you.

In US, I enter today's date as 6/8/06, as a String. If I store it in the database as string, it will be stored as "6/8/06" (no changes).
Now, I buddy of mine in Italy opens the same record and what he/she gets is August 6, 2006 (because the String is converted using European standards). And that is wrong.

If, on the other hand, I convert the String as a Date, it will be stored as a Date (internal format, no language dependent). The pc of my Italian buddy will convert correctly to June 8, 2006

Marco

...But if you store date in the numeric format(6/8/06) it is treated as the American format in all Windows platform...
I still do not understand. As you just said, 6/8/06 is NOT a numeric format. The only way to store a string in a numeric format that is the same for all regional setting is to store it as a Date.

That is, I create a table with a column called DateOfTheEvent (or whatever), and I define its type as a Date (not a String or Integer or anything else)
If I read the date from a Text control for example, I will store as

MyRecord.Fields("DateOfTheEvent").Value = CDate(myText.Text)

in this way, just like you said, the date is stored internally in a regional setting independent way.
To retrive the value:

myText.Text = MyRecord.Fields("DateOfTheEvent").Value

And VB, because it knows the the internal value is stored as Date, will convert automatically the value using the current settings

I have the idea we are saying the same thing just with different words :)

Marco

I think we can summize that dates should always be stored as Date in a table, as opposed to strings.

We all agree with you softraj, use Date not integer/string/long or anything else.

mstraf,I do not think you've understood the gist of the topic we were discussing.More importantly,I do not think you've got the basics right.
In your very 1st posting you've stated "what I've retrieved is 20-09-04 where 20 is day, 09 is month and 04 is year".What you think is a month(9) will not be considered as a month in any Windows platform.And the result "9/4/2020" is also valid - in keeping with the fact that "20-09-04" is not a valid American format.
My request to you is re-read all my postings & test it out in your computer & then you'll know the import of what all I've been stating.

I agree......but I'm not telling with WHOM I agree!

Dates are dates and should be stored as dates. SO THERE! :-
Dates are dates and strings are strings.

Now that I work for a UK software company who has installations all over the world, this is an important thing to remember!

Love and kisses,
L

While I'm here, does anyone know the order of wire colors for a straight-through cable? :o)

Hey Laurel - looks like you've done the opposite to me - USA > UK / UK > USA.

P.S. www.nullmodem.com if a good source for cabling info.

I've never heard of Kildrummy. Kind of like MRP software I guess...

I'm working for a company in California who provide consultancy services for the landfill industry, and distribute the instruments I used to work with in the UK. http://www.ces-landtec.com/