[AccessD] Date standardization

Gustav,

I don't understand this.  How is this a "classic issue"?

To me, the classic issue is that imported dates will always be correct.

I am in a non-US country, and manage dates accordingly.  In the immediate 
window...
? Date
17/06/2010

I can set the Format of date fields in the table design (normally I would 
not, there is no reason to, but I could) to dd-mmm-yy.  I can set the Format 
property of all date controls to something similar.  I can send that 
database to someone in the US, and they can import that into their database, 
and the dates will be displayed in *their* chosen date format, and the dates 
will be correct.  If I had entered 3/05/2010, in their US system it will 
show as 5/03/2010.  They don't need to "know which format the dates were 
originally created in".  In fact, as you know, from a data point of view, 
there is no such thing as the "format the dates were originally created in".

Of course, I am assuming we are talking Access BE to Access BE here. 
Importing date data from text files or spreadsheets or other database types 
has complications that have to be overcome, and sometimes takes a bit of 
careful thought.  But it sounded like Doug's scenario was Access.

Regards
Steve


--------------------------------------------------
From: "Gustav Brock" <Gustav at cactus.dk>
Sent: Thursday, June 17, 2010 2:52 AM
To: <accessd at databaseadvisors.com>
Subject: Re: [AccessD] Date standardization

> Hi Doug
>
> Ah, that explains. A classic issue.
>
> /gustav
>
>
>>>> dbdoug at gmail.com 16-06-2010 16:44 >>>
> Sorry, you're right - the situation I had was with an offline BE where the
> data was being imported into the main BE periodically.  The import routine
> didn't 'know' which format the dates were originally created in.
>
> Doug
>
> On Wed, Jun 16, 2010 at 6:41 AM, Gustav Brock <Gustav at cactus.dk> wrote:
>
>> Hi Doug
>>
>> But that is not because of the regional settings but because validation 
>> is
>> missing and/or if the user types the date in a way not according to the
>> regional settings. 11/6/10 (November) can be perfectly valid (think of a
>> booking system), but if future dates are not allowed, the app must 
>> validate
>> input and prompt the user.
>