IMO the American date format is appropiate.

Here's the logic.
1/12/2004 should read January 1st, 2004 not december 1st, 2004.

Since all English speaking people read from left to right it just makes sense.

That's my opinion. :)

Hmmm, logic.... I think things get much more confusing when 1/12 is January 1st.... ;)

Anyway, it still depends on what you expect to read.

In the Netherlands, we read from Left to Right as well. However, we don't say January Twelfth, but Twelfth January, so unfortunately this doesn't work for us. For us, mentioning the Day before the Month makes much more sense.

Personally, I don't think there is a right or wrong. I can live with any standard that exists, as long as anyone sticks to the same standard.


Imar


---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.

very funny!! but I agree totally - as I said before, logic suggests you start with the smallest unit and work towards the biggest [or equally valid to go vice versa], but it makes no sense to start in the middle [month] then go 'downwards' to the day, and then jump 'upwards' in effect two places to the year. I wonder how American date format handles time, out of interest? Would it be expressed as minutes/seconds/hours - that would seem to match the months/days/years thinking.

to return to the main topic, though, I have very little experience with Access, and so far haven't been able to get it to work. If I enter an 'impossible' date - eg in its terms the 5th day of the 22nd month, it automatically converts it to the 22nd day of the 5th month. However, if you have an ambiguous date, such as the 7th day of the 3rd month/3rd day of the 7th month, it just leaves it, so in effect you're not sure which of the two possible options it is interpreting. Does that sound as clear as a muddy football pitch?!

I'm hoping to get to grips with MySQL in the near future - do you think I'd get on better with that?

And finally, glad you are also a fan of Ruud... I was disappointed to learn of the rifts within the Dutch national team, and hope it doesn't have too much of an adverse effect on Euro 2004 for them. If the English team can remember to turn up for medical appointments intead of going shopping, they might have a chance as well ;)

:);)

Well, it does make sense. The database doesn't bother trying to convert your date unless you pass it something it doesn't understand (personally, I'd prefer you'd get an error, instead of the silent conversion).

This means that when you don't get a conversion when you pass 02/25/2004, this is the format you should pass to the database. Otherwise, you should pass 25/02/2004.

The problem with this issue is that there is no single answer to fix it. This problem has it roots in "Regional Settings", settings that change the way your system handles and displays dates, currency, time (minutes/seconds/hours for the US settings ;) )
Apparently, your system is set up to use UK dates.

There are, however a couple of solutions / work arounds.

1. Set your system to the US locale in the Region Settings. (That is, give in to the US format....) I do that with any servers I setup so at least I know what to expect from the system. If you do that, the code from the book should work as it uses the US format. On a desktop system, it may not be applicable, as it changes all your "locale" settings in all applications.

2. Use a DatePicker for your dates, and have them return a date format that fits your database. Two freeware examples:

http://www.softcomplex.com/products/tigra_calendar/
http://www.totallysmartit.com/exampl...dar/simple.asp

The advantage of this solution is that you know how you're receiving your date. It's clear that 12/01/2004 means January 12, not December first (or the other way around ;) )

3. Offer your user three drop-downs: one for the days, one for the months and one for the years. This way, you know what data you're getting, so you can construct your own valid date. This is not very user friendly, and it allows for dates like 30-02-2004, but it can be useful in some circumstances.

4. Have Dreamweaver convert the date for you. The Dynamic Text fields allow you to convert the date before it gets passed to the database. Take a look at the function that Dreamweaver inserts and modify it to fit your format.

Access understands the format CCYY/MM/DD. so use that to your advantage. If you get used to formatting your dates (inside the system, not in the UI of course), you'll have less trouble using other databases like SQL Server in the future.

In all scenario's, you'll have to do some hand coding. You'll need to convert the values you pass in you SQL statement, before they get sent to the database.

I haven't used MySQL in an ASP environment much, although I have used it with PHP. The larger sites I have designed and built usually use Microsoft SQL Server as the back end database, although Access can have its use at times as well.


Cheers,

Imar



---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.

many thanks, Imar - that is all a *big* help...

Anne
:)