If I use a com.google.gwt.i18n.client.DateTimeFormat with my own pattern, like "yyyy-MM-dd", I run into the situation described in the Javadocs under "Additional Parsing Considerations" if the user enters a two digit year 00 (most likely intending it to be the year 2000).
The following code:
DateTimeFormat fmt = DateTimeFormat.getFormat("yyyy-MM-dd");
Date d = fmt.parse("00-01-01");
System.out.println(d + " getYear: " + d.getYear() + " getTime: " + d.getTime());
long d1 = d.getTime();
d = fmt.parse("01-01-01");
System.out.println(d + " getYear: " + d.getYear() + " getTime: " + d.getTime());
long d2 = d.getTime();
long diff = d2 - d1;
System.out.println((diff/1000.0/60/60/24/366));
Results in:
Thu Jan 01 00:00:00 EST 1 getYear: -1899 getTime: -62167374000000
Sat Jan 01 00:00:00 EST 1 getYear: -1899 getTime: -62135751600000
1.0
So, I believe that internally the date is on the right year, since the two dates are different by 366 days (apparently year 0 was a leap year), but when getting the year from it, it adjusts year 0 to 1.
This is messing up logic I have with a custom extension of DateTimeFormat to adjust how two-digit years are parsed - the first step in parse is super.parse(text), and then I do my own adjustment by 1900 or 2000 after that. So, entries of 00 are being turned into 2001.
This is actually a Java "problem", and we can get into a long metaphysical discussion of whether there really should be a year 0 or not, but it does affect parsing, and I believe that the way that DateTimeFormat handles two-digit years supplied to a "yyyy" pattern brings it to the forefront. So, the question is, should GWT's Date emulation be faithful to its Java equivalent, or behave in a manner consistent with DateTimeFormat?
-- The following code:
DateTimeFormat fmt = DateTimeFormat.getFormat("yyyy-MM-dd");
Date d = fmt.parse("00-01-01");
System.out.println(d + " getYear: " + d.getYear() + " getTime: " + d.getTime());
long d1 = d.getTime();
d = fmt.parse("01-01-01");
System.out.println(d + " getYear: " + d.getYear() + " getTime: " + d.getTime());
long d2 = d.getTime();
long diff = d2 - d1;
System.out.println((diff/1000.0/60/60/24/366));
Results in:
Thu Jan 01 00:00:00 EST 1 getYear: -1899 getTime: -62167374000000
Sat Jan 01 00:00:00 EST 1 getYear: -1899 getTime: -62135751600000
1.0
So, I believe that internally the date is on the right year, since the two dates are different by 366 days (apparently year 0 was a leap year), but when getting the year from it, it adjusts year 0 to 1.
This is messing up logic I have with a custom extension of DateTimeFormat to adjust how two-digit years are parsed - the first step in parse is super.parse(text), and then I do my own adjustment by 1900 or 2000 after that. So, entries of 00 are being turned into 2001.
This is actually a Java "problem", and we can get into a long metaphysical discussion of whether there really should be a year 0 or not, but it does affect parsing, and I believe that the way that DateTimeFormat handles two-digit years supplied to a "yyyy" pattern brings it to the forefront. So, the question is, should GWT's Date emulation be faithful to its Java equivalent, or behave in a manner consistent with DateTimeFormat?
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment