SimpleDateFormat Problem while Parsing Date/time String on Japanese OS

Discussion in 'Java' started by shilpa, Sep 3, 2005.

  1. shilpa

    shilpa Guest

    Hi there,

    I am trying to parse Date/Time String : 2001/05/10 3:45:35 on Japanese
    OS.

    I know we can have exact Date Time formatting pattern to match this
    string and can parse it easily.

    But I am wondering why Date/Time Pattern yy/MM/dd hh:mm matches for
    this string and return me date as : Thu May 10 03:45:00 PDT 2001 on
    Japanese OS.

    and because of this I am loosing seconds.

    Does anybody knows why this is happening?

    I have setLenient(false).

    Best Regards,
    Shilpa
    shilpa, Sep 3, 2005
    #1
    1. Advertising

  2. shilpa

    Roedy Green Guest

    On 3 Sep 2005 09:25:02 -0700, "shilpa" <> wrote
    or quoted :

    >I am trying to parse Date/Time String : 2001/05/10 3:45:35 on Japanese
    >OS.
    >
    >I know we can have exact Date Time formatting pattern to match this
    >string and can parse it easily.


    It is not a bug, it's a feature!

    quoting from
    http://java.sun.com/j2se/1.5.0/docs/api/java/text/SimpleDateFormat.html

    -------------------------------
    Year: For formatting, if the number of pattern letters is 2, the year
    is truncated to 2 digits; otherwise it is interpreted as a number.

    For parsing, if the number of pattern letters is more than 2, the year
    is interpreted literally, regardless of the number of digits. So using
    the pattern "MM/dd/yyyy", "01/11/12" parses to Jan 11, 12 A.D.

    For parsing with the abbreviated year pattern ("y" or "yy"),
    SimpleDateFormat must interpret the abbreviated year relative to some
    century. It does this by adjusting dates to be within 80 years before
    and 20 years after the time the SimpleDateFormat instance is created.
    For example, using a pattern of "MM/dd/yy" and a SimpleDateFormat
    instance created on Jan 1, 1997, the string "01/11/12" would be
    interpreted as Jan 11, 2012 while the string "05/04/64" would be
    interpreted as May 4, 1964.

    During parsing, only strings consisting of exactly two digits, as
    defined by Character.isDigit(char), will be parsed into the default
    century. Any other numeric string, such as a one digit string, a three
    or more digit string, or a two digit string that isn't all digits (for
    example, "-1"), is interpreted literally. So "01/02/3" or "01/02/003"
    are parsed, using the same pattern, as Jan 2, 3 AD. Likewise,
    "01/02/-3" is parsed as Jan 2, 4 BC.
    ---------------------------------

    So if you want to be strict, you must do your own format check first
    to make sure the fields are the correct length.

    You could invent a simple mask checking class that allowed a mask to
    be defined something like this:

    "9999/99/99 Z9:99:99"

    /-: must be literally that value.
    9 must be digit 0-9
    Z must be space or digit 0-9
    space must be space
    A - must be upper case letter
    a - must be lower case letter


    or if you wanted to permit variable width fields, write a regex
    checker.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
    Roedy Green, Sep 5, 2005
    #2
    1. Advertising

  3. shilpa

    shilpa Guest

    Thank you ....
    Actually pattern yy/MM/dd hh:mm is matching for string 2001/05/10
    3:45:35.
    So my date part is coming fine..but I am loosing seconds.
    i.e: my date after parsing string is: Thu May 10 03:45:00 PDT 2001

    So time is wrong, why it is matching "hh:mm" for string 03:45:00 ?
    shilpa, Sep 5, 2005
    #3
  4. shilpa

    Roedy Green Guest

    On 4 Sep 2005 23:46:11 -0700, "shilpa" <> wrote
    or quoted :

    >Thank you ....
    >Actually pattern yy/MM/dd hh:mm is matching for string 2001/05/10
    >3:45:35.
    >So my date part is coming fine..but I am loosing seconds.
    >i.e: my date after parsing string is: Thu May 10 03:45:00 PDT 2001
    >
    >So time is wrong, why it is matching "hh:mm" for string 03:45:00 ?


    I am sorry I can't follow what you are saying. Please post the code
    with your parse mask and a sample date you are parsing.

    You seem to be saying your mask has no seconds part, and you are
    puzzled why you are losing seconds. That makes no sense.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
    Roedy Green, Sep 5, 2005
    #4
  5. shilpa

    shilpa Guest

    My code is generic code which will loop thr' all date/time format and
    will try to find match.
    What I am saying is on Japanese System pattern : yy/MM/dd hh:mm is
    getting matched for String " 2001/05/10 3:45:35"
    and becos of this I am lossing seconds. My code part is:

    int[] dStyle = {DateFormat.SHORT, DateFormat.MEDIUM, DateFormat.LONG,
    DateFormat.FULL};

    int dS, i ;

    for (i=0; i < dateStyles.length && flag== false; i++)
    {
    dS = dStyle;
    try
    {
    dateFormat = DateFormat.getDateTimeInstance(dS,
    dStyle);
    dateFormat.setLenient(false);
    date = dateFormat.parse(stringDateTime);
    flag= true;

    }
    catch(Exception e)
    {

    }






    Roedy Green wrote:
    > On 4 Sep 2005 23:46:11 -0700, "shilpa" <> wrote
    > or quoted :
    >
    > >Thank you ....
    > >Actually pattern yy/MM/dd hh:mm is matching for string 2001/05/10
    > >3:45:35.
    > >So my date part is coming fine..but I am loosing seconds.
    > >i.e: my date after parsing string is: Thu May 10 03:45:00 PDT 2001
    > >
    > >So time is wrong, why it is matching "hh:mm" for string 03:45:00 ?

    >
    > I am sorry I can't follow what you are saying. Please post the code
    > with your parse mask and a sample date you are parsing.
    >
    > You seem to be saying your mask has no seconds part, and you are
    > puzzled why you are losing seconds. That makes no sense.
    > --
    > Canadian Mind Products, Roedy Green.
    > http://mindprod.com Again taking new Java programming contracts.
    shilpa, Sep 5, 2005
    #5
  6. shilpa

    Chris Uppal Guest

    shilpa wrote:

    > What I am saying is on Japanese System pattern : yy/MM/dd hh:mm is
    > getting matched for String " 2001/05/10 3:45:35"
    > and becos of this I am lossing seconds.


    The DateFormat.parse() method looks for a parseable date at the /begining/ of
    the supplied string, it does not require that the parsed date is /all/ of the
    supplied string (poor API design, but there you go...). In your case you need
    to be able to tell how much of the String was actually a formatted date, so you
    will have to use the alternate form of DateFormat.parse() that takes a
    ParsePosition argument too.

    -- chris
    Chris Uppal, Sep 5, 2005
    #6
  7. shilpa

    shilpa Guest

    Thanks Chris :)
    Yeah, I guess this is the issue...will try and will let you know about
    same.

    Cheers :)
    Shilpa

    Chris Uppal wrote:
    > shilpa wrote:
    >
    > > What I am saying is on Japanese System pattern : yy/MM/dd hh:mm is
    > > getting matched for String " 2001/05/10 3:45:35"
    > > and becos of this I am lossing seconds.

    >
    > The DateFormat.parse() method looks for a parseable date at the /begining/ of
    > the supplied string, it does not require that the parsed date is /all/ of the
    > supplied string (poor API design, but there you go...). In your case you need
    > to be able to tell how much of the String was actually a formatted date, so you
    > will have to use the alternate form of DateFormat.parse() that takes a
    > ParsePosition argument too.
    >
    > -- chris
    shilpa, Sep 5, 2005
    #7
  8. shilpa

    shilpa Guest

    Thanks Chris..Its working perfectly fine...:)

    I have one more doubt here...On German OS pattern "dd.MM.yyyy H:mm"
    matches for date/time "19.05.97 00:00"

    and returns me wrong date : Fri May 19 00:00:00 GMT+05:30 0097 .

    Any comments on this?

    Thanks,
    Shilpa
    shilpa, Sep 5, 2005
    #8
  9. shilpa

    Chris Uppal Guest

    shilpa wrote:

    > I have one more doubt here...On German OS pattern "dd.MM.yyyy H:mm"
    > matches for date/time "19.05.97 00:00"
    >
    > and returns me wrong date : Fri May 19 00:00:00 GMT+05:30 0097 .
    >
    > Any comments on this?


    Not really. I'm not sure whether this is a bug, but on the whole I suspect
    not. In either case you have to work around it.

    One thing I'd do is try all the options, rather than stopping at the first one
    that "worked". That would have two benefits, one is that you could detect when
    you had an ambiguous date and try to deal with that ambiguity somehow (throw an
    excpetion, prompt the user for more data, select one option arbitrarily but
    write a log entry to say that you have done so,.... whatever). The second is
    that you could handle cases like this rather better.

    I guess you need a layer of sanity checking anyway (to eliminate dates like
    0097 AD for instance ;-), and you could use that together with the complete
    list of possible interpretations to make the system more reliable. First work
    out all the interpretations that the parse() method thinks are OK, and then
    filter that by removing all the implausible values. If that leaves exactly one
    candidate then accept it, otherwise go into some sort of error recovery mode.

    -- chris
    Chris Uppal, Sep 5, 2005
    #9
    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. Bill Angel
    Replies:
    4
    Views:
    1,344
    Bill Angel
    Sep 28, 2003
  2. Kyote
    Replies:
    16
    Views:
    4,158
    Michael Borgwardt
    Oct 24, 2003
  3. Peter Grison

    Date, date date date....

    Peter Grison, May 28, 2004, in forum: Java
    Replies:
    10
    Views:
    3,229
    Michael Borgwardt
    May 30, 2004
  4. Replies:
    2
    Views:
    913
  5. Scott Harper
    Replies:
    2
    Views:
    13,643
    Scott Harper
    Apr 3, 2006
Loading...

Share This Page