Localizing dates

[Chris]

In the US, the most common date format is mm/dd/yyyy. In Europe, it's
dd/mm/yyyy.

Is there any way to know which format to use, based on the Locale? It
doesn't appear that java.text.DateFormat or java.text.DateFormatSymbols know
about or acknowledge the difference. Or maybe they do -- I can't tell.

I need to know because I have to parse dates in different locations, and I
want to give the parser a hint about what format to expect. The default
parser in DateFormat is lame, so I need to write my own. Specifying a
format explicitly at run time is not a possibility.

 

[Paul Tomblin]

I need to know because I have to parse dates in different locations, and I
want to give the parser a hint about what format to expect. The default
parser in DateFormat is lame, so I need to write my own. Specifying a
format explicitly at run time is not a possibility.

DateFormat isn't that bad for parsing stuff in a file or putting things
output, but I haven't found a good way to parse input dates in a gui.

One thing I had to do in my code: For some bizarre reason, Java thinks
that Italy uses "." between fields in a time stamp, even though our
localization experts and translators said no, we need to use colons like
all the other European languages. So I get the current instance of the
time format, and then if the time is a SimpleDateFormat, make a new
SimpleDateFormat with the dots replaced by colons.

// This is an incredibly ugly hack, but it's based on the fact that
// Java for some reason decided that Italy uses "." between
// hours.minutes.seconds, even though "locale" and strftime say
// something different.
hmsTimeFormat = DateFormat.getTimeInstance(DateFormat.MEDIUM);
if (hmsTimeFormat instanceof SimpleDateFormat)
{
String str = ((SimpleDateFormat)hmsTimeFormat).toPattern();
str = str.replace('.', ':');
hmsTimeFormat = new SimpleDateFormat(str);
}

Maybe you could do a similar trick - get the current date instance, and if
it turns out to be an instanceof SimpleDateFormat, grab the locations of
where each bit is by parsing the pattern.

 

[anders t]

Quoting Chris in comp.lang.java.programmer:

in Europe, it's dd/mm/yyyy.

Is it? I thought it was yyyy-mm-dd. But that's perhaps to logical and makes
sorting too simple... =)

 

[Mark Thornton]

Quoting Chris in comp.lang.java.programmer:



Is it? I thought it was yyyy-mm-dd. But that's perhaps to logical and makes
sorting too simple... =)

No that is ISO8601 format (an international standard). While common, it
is not the traditional date format anywhere in Europe (as far as I know).

 

[anders t]

Quoting Mark Thornton in comp.lang.java.programmer:

that is ISO8601 format (an international standard). While common, it
is not the traditional date format anywhere in Europe (as far as I know).

"Traditional" is sort of misleading here. It isn't the "traditional" format
in Sweden, as in used for hundreds of years, but it sure is used _widely_
now. Widely enough to make it the standard nowadays.

And I honestly can't understand why the software community still largely
chooses to tweak around with those other formats.

 

[Thomas Weidenfeller]

And I honestly can't understand why the software community still largely
chooses to tweak around with those other formats.

Because there are these people called "users". Especially the
non-technical types like to see dates and times the way they are used
to. I am a big fan of ISO8601, too, but not everyone is. So one can't
avoid it completely when reading or displaying dates and times.

For internal storage, there is IMHO only one way: An int or long, e.g.
seconds or milliseconds since the Unix epoch. And, like the Unix
epoch, based on GMT only.

/Thomas

 

[anders t]

Quoting Thomas Weidenfeller in comp.lang.java.programmer:

Because there are these people called "users". Especially the
non-technical types like to see dates and times the way they are used
to. I am a big fan of ISO8601, too, but not everyone is. So one can't
avoid it completely when reading or displaying dates and times.

For internal storage, there is IMHO only one way: An int or long, e.g.
seconds or milliseconds since the Unix epoch. And, like the Unix
epoch, based on GMT only.

But there are Swedish users, too... How come we cope with it while, for
instance, US Americans don't seem to?

In Sweden, yyyy-mm-dd is everywhere. The only time you'd perhaps /expect/
dd/mm, yyyy is in a handwritten /personal/ letter or in spoken Swedish.
You'd certainly not expect it in a professional letter or from some
authority. At least this is my experience.

 

[Tony Dahlman]

In the US, the most common date format is mm/dd/yyyy. In Europe, it's
dd/mm/yyyy.

Is there any way to know which format to use, based on the Locale? It
doesn't appear that java.text.DateFormat or java.text.DateFormatSymbols know
about or acknowledge the difference. Or maybe they do -- I can't tell.

I need to know because I have to parse dates in different locations, and I
want to give the parser a hint about what format to expect. The default
parser in DateFormat is lame, so I need to write my own. Specifying a
format explicitly at run time is not a possibility.

Hi Chris!

When using classes like DateFormat, look for factory methods like the static
methods:
DateFormat.getDateInstance()
DateFormat.getDateTimeInstance()
DateFormat.getTimeInstance()

....which are very helpful for what you seem to want to do. Some of the variations
also allow your code to specify the Locale, so you can use the java.util.Locale
and related methods if you need them, but most often you will not.

Regards -- Tony Dahlman

 

[Tony Dahlman]

In the US, the most common date format is mm/dd/yyyy. In Europe, it's
dd/mm/yyyy.

Is there any way to know which format to use, based on the Locale? It
doesn't appear that java.text.DateFormat or java.text.DateFormatSymbols know
about or acknowledge the difference. Or maybe they do -- I can't tell.

I need to know because I have to parse dates in different locations, and I
want to give the parser a hint about what format to expect. The default
parser in DateFormat is lame, so I need to write my own. Specifying a
format explicitly at run time is not a possibility.

Hi Chris!

When using classes like DateFormat, look for factory methods like the static
methods:
DateFormat.getDateInstance()
DateFormat.getDateTimeInstance()
DateFormat.getTimeInstance()

....which are very helpful for what you seem to want to do. Some of the variations
also allow your code to specify the Locale, so you can use the java.util.Locale
and related methods if you need them, but most often you will not.

Regards -- Tony Dahlman

 

[Tony Dahlman]

In the US, the most common date format is mm/dd/yyyy. In Europe, it's
dd/mm/yyyy.

Is there any way to know which format to use, based on the Locale? It
doesn't appear that java.text.DateFormat or java.text.DateFormatSymbols know
about or acknowledge the difference. Or maybe they do -- I can't tell.

I need to know because I have to parse dates in different locations, and I
want to give the parser a hint about what format to expect. The default
parser in DateFormat is lame, so I need to write my own. Specifying a
format explicitly at run time is not a possibility.

Hi Chris!

When using classes like DateFormat, look for factory methods like the static
methods:
DateFormat.getDateInstance()
DateFormat.getDateTimeInstance()
DateFormat.getTimeInstance()

....which are very helpful for what you seem to want to do. Some of the variations
also allow your code to specify the Locale, so you can use the java.util.Locale
and related methods if you need them, but most often you will not.

Regards -- Tony Dahlman