At 8:48 PM -0800 2/9/2001, "Monte Goulding" <[EMAIL PROTECTED]>
wrote:
>Not everyone here works on a Mac. I agree that it would be good to have an
>mc function that told me what the system settings were but to have put the
>date return an unknown format would be a "bloody disaster". The amout of
>workarounds we'd all need to do to determine the format would be counter
>productive.
>
>As I said before another convert function or a global property that gave the
>format as a string would be the best souloution but until then I'm quite
>happy using the abbrev date because at least it's understood by the user and
>is consistent to any date handling I'm doing.
You can't assume everyone understands or expects the US date format. If you
ask for a date and the user types "8/2/01", is that user giving a date in
August or February? It depends.
The same thing goes for displayed dates.
Right now, if someone wants to develop a stack that works for users
worldwide, they have to either ask the user to enter their preferred date
format - ridiculous, since it's already available in the system settings -
or specify, each time a date is requested or displayed, that dates must be
MM/DD/YY. Or avoid using short dates altogether. All of this looks most
unprofessional and unfinished in an application, apart from the annoyance
it causes users.
If you need an invariant date format, use the English date, the seconds, or
the dateItems; that's what they're there for, so you can have a date format
that never changes. Assuming everyone uses the same format for displayed
dates is asking for trouble.
Archives: http://www.mail-archive.com/[email protected]/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send bug reports to <[EMAIL PROTECTED]>, not this list.
