Localizing dates

Discussion in 'Java' started by Chris, Jan 28, 2005.

  1. Chris

    Chris Guest

    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.
    Chris, Jan 28, 2005
    #1
    1. Advertising

  2. Chris

    Paul Tomblin Guest

    In a previous article, "Chris" <anon> said:
    >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.

    --
    Paul Tomblin <> http://xcski.com/blogs/pt/
    "Integration by parts -- a very powerful technique."
    Teaching by intimidation -- also a very powerful technique.
    -- Logan Shaw, quoting Chuck Odle, his Calculus teacher
    Paul Tomblin, Jan 29, 2005
    #2
    1. Advertising

  3. Chris

    anders t Guest

    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... =)



    --
    All that we see, or seem,
    is but a dream, within a dream,
    installed by the Machine
    anders t, Jan 29, 2005
    #3
  4. anders t wrote:
    > 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... =)
    >


    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).
    Mark Thornton, Jan 29, 2005
    #4
  5. Chris

    anders t Guest

    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.



    --
    All that we see, or seem,
    is but a dream, within a dream,
    installed by the Machine
    anders t, Jan 29, 2005
    #5
  6. anders t wrote:
    > 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

    --
    The comp.lang.java.gui FAQ:
    ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq
    Thomas Weidenfeller, Jan 31, 2005
    #6
  7. Chris

    anders t Guest

    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.


    --
    All that we see, or seem,
    is but a dream, within a dream,
    installed by the Machine
    anders t, Jan 31, 2005
    #7
  8. Chris

    Tony Dahlman Guest

    Chris wrote:

    > 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

    --
    ---------------------------------------
    nospam, I've had it, thanks.
    Tony Dahlman, Feb 22, 2005
    #8
  9. Chris

    Tony Dahlman Guest

    Chris wrote:

    > 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

    --
    ---------------------------------------
    nospam, I've had it, thanks.
    Tony Dahlman, Feb 22, 2005
    #9
  10. Chris

    Tony Dahlman Guest

    Chris wrote:

    > 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

    --
    ---------------------------------------
    nospam, I've had it, thanks.
    Tony Dahlman, Feb 22, 2005
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. David Lozzi

    Dates dates dates dates... SQL and ASP.NET

    David Lozzi, Sep 29, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    839
    Rob Schieber
    Sep 30, 2005
  2. Chris

    Localizing dates

    Chris, Jan 28, 2005, in forum: Java
    Replies:
    1
    Views:
    446
  3. PW

    Dates! Dates! Dates!

    PW, Aug 7, 2004, in forum: ASP General
    Replies:
    4
    Views:
    172
    Mark Schupp
    Aug 9, 2004
  4. Replies:
    1
    Views:
    192
    Jano Svitok
    Jul 17, 2007
  5. kellygreer1

    RFC-822 dates into Ruby dates

    kellygreer1, Jun 8, 2008, in forum: Ruby
    Replies:
    1
    Views:
    175
    Eric I.
    Jun 8, 2008
Loading...

Share This Page