I agree with Doug that users should be allowed to use their own regional format. Forcing them to use an unfamiliar format is likely to produce bad data, 4 July becoming 7 April for instance. We use the dd/mm/yyyy format as the usual standard here,
but I send a lot of files to the USA, so I generally just leave the format of controls in forms and reports as the default of Short Date. That way they see the dates as mm/dd/yyyy. If your system short date format is dd-mm-yyyy you'd see them like
that. The important thing is that the actual date/time values as stored in the database are the same, being no more than a 64 bit floating point number as an offset from 30 December 1899 00:00:00.
The one area where I do find I have to compromise is with time formats as Americans don't like the 24 hour clock we in Yurp tend to use as standard in formal contexts. They call it 'military time'. So I have to go back to formatting times as AM and PM when sending stuff across the pond.
Another option with dates is to use an internationally unambiguous format. The US and UK army signallers did this in The Second World War after confusion arose, agreeing on a standard of dd mmmm yyyy.
Date literals in code or SQL must of course be either in US short date format mm/dd/yyyy or an internationally unambiguous format. I favour the ISO standard of YYYY-MM-DD.
The one area where I do find I have to compromise is with time formats as Americans don't like the 24 hour clock we in Yurp tend to use as standard in formal contexts. They call it 'military time'. So I have to go back to formatting times as AM and PM when sending stuff across the pond.
Another option with dates is to use an internationally unambiguous format. The US and UK army signallers did this in The Second World War after confusion arose, agreeing on a standard of dd mmmm yyyy.
Date literals in code or SQL must of course be either in US short date format mm/dd/yyyy or an internationally unambiguous format. I favour the ISO standard of YYYY-MM-DD.
Ken Sheridan, Stafford, England