Dates and MS SQL

Question

Hi - I'm having a hard time with dates and MS SQL as I've
just upgraded our DB from Access and it's doing my head in.
The problem I'm having is when I input a date such as
10/05/2006 it is being displayed as 05/10/2006 and then if I update
the record it switches back to 10/05/2006 and vice-a-versa.
In my text field the code is :
value="#DateFormat(lastcalled, 'dd/mm/yyyy')#"
when I submit to db the code is:
lastcalled=#CreateODBCDateTime(lastcalled)#
If I take the dateFormat off I don't get the problem however
the date isn't displayed correctly.
I'm sure it's something small that I'm missing.....
Regards,
Jared.

Answer 1

> The problem I'm having is when I input a date such as
10/05/2006
The problem here can be summarised by asking a person from
USA what that
date is, then asking someone from a different country.
A USAn will say "5 October". Almost everyone else will say
"10 May".
A computer will do much the same thing, depending on its
locale settings.
One the other hand, if you have "13/10/2006" (or
"10/13/2006"), almost
anyone, from wherever they are (and computers, generally,
too), will work
out it's NOT "the tenth of Thirteenember", it's "13 Oct".
The problem here is that dd/mm/yyyy or mm/dd/yyyy -formatted
strings are
ambiguous for about a third of the year (from the first to
the twelfth of
each month).
If your locale settings are uniform across the board
(INCLUDING the "locale
settings" of the person entering the date), then you can get
away with
allowing them to input dd/mm/yyyy (or mm/dd/yyyy, if you must
However it's trick to get the humans doing the data entry to
behave, so
simply having:
Enter your birthday: [ ]
Is not gonna work all the time, cos you might enter 4/5/66,
but I might
enter 5/4/66. Even if you do this:
Enter your birthday (dd/mm/yyyy): [ ]
People will ignore you. I guess you can then ***-u-me they
did what
they're told, but it's still not optimal.
The best option is to break the dd, the mm and the yyyy bits
down into
separate inputs. Either have three text inputs, three drop
downs, a
date-selector-widget, or something like that, in which there
is no scope
left for ambiguity.
Then you always know which bits of data represent which bits
of the date,
and you never have any ambiguity problems.
Adam