JDK-4234799 : DateFormat maps two DIFFERENT times into the same numeric
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.text
  • Affected Version: 1.1.8
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_nt
  • CPU: x86
  • Submitted: 1999-05-03
  • Updated: 2000-02-15
  • Resolved: 2000-02-15
Related Reports
Duplicate :  
JDK-4312621 - (cal) API: DST transition handling is ambiguous in GregorianCalendar
Relates :  
JDK-4284987 - API: GregorianCalendar: undefined behaviour on daylight saving boundary
Description

Name: vi73552			Date: 05/03/99


This problem appears to be the mapping between "numeric" to "String Liturals" NOT being ONE-TO-ONE.
(Well, that is my guess and what it appears to be!)

The easiest way to reproduce this is by using the one of the "DEMO" codes download from Sun for JDK 1.1.8 (also happened on 1.1.7b) under the dir say "D:\jdk1.1.8\demo\i18n\DateTimeFormat\example1.html"

1. Load the applet
(With all setting being default, well for me at least! will be:

[Localized Pattern] = unckecked
[Validation Mode] = unckecked
[City] = Washington
[Date Fields] = Year
[Roll] = true
[Locale] = English (United States)
[Date and Time Format] = true
[Date Style] = Full
[Time Style] = Full

2. Set the [Pattern] field to "yyyy/DDD HH:mm:ss"

3. Set the [New Date] field to "1999/094 02:xx:xx" (where "x" can be any number say "0" zeros)
(let use "1999/094 02:22:55")

4. Pay attention to the [Millis] field (write it down if you want)
(if you use my value, you'll get
923206975000)

5. Now set the [New Date] field to "1999/094 01:xx:xx"
(Basically just change the hour from "02" to "01")

6. Observe what the [Millis] field give you!!
(Yip! the Same exact numeric value. When in fact, it shouldn't!!!)

(Note: also try these values:
...
1995/092 02:xx:xx
1996/098 02:xx:xx
1997/096 02:xx:xx
1998/095 02:xx:xx
1999/094 02:xx:xx
2000/093 02:xx:xx
2001/091 02:xx:xx
2002/097 02:xx:xx
2003/096 02:xx:xx
2004/095 02:xx:xx
...
)

I'm using this pattern (yyyy/DDD HH:mm:ss) on my Java application and the same behavior is observed.

This means given a year, there's at least one day, one hour your time will act funky!!
Because your hours "01" and "02" get mapped to the SAME numeric value.

Please! Please! fix this!!  :(
(Review ID: 57351) 
======================================================================
Comments
WORK AROUND Name: vi73552 Date: 05/03/99 Well coming up with your own "Date" object is certainly one, but NOT very easy. Since the mapping goes from e.g. 1 -> '1' 1 -> '2' 2 -> '3' 3 -> '4' ... I don't really know any "quick" solution having my part NEEDS to get from a numeric to a String literal and vis versa. ======================================================================
11-06-2004
PUBLIC COMMENTS 1999/04/04 01:30:00 and 1999/04/04 02:30:00 has same millisecond value, since this is at when daylight swithing takes place.CLO
10-06-2004
EVALUATION Looks like some side effect of the switch to daylight savings time. The 02:xx:xx strings specify a time that doesn't exist, and instead of throwing an exception, the formatter just maps it to some other time. The documentation doesn't say how this should be handled. norbert.lindenberg@Eng 1999-05-03 This is not the bug. 1999/094 is 1999/04/04. And the day of daylight swithing. Thus, 01:22:55 and 02:22:55 is same time in UTC (millisecond) form. koushi.takahashi@japan 1999-09-21 There is still room to be discussed about the specification of this issue. Actually, this is the problem of GregorianCalendar that how to hundle the hour on daylight swith boundary. ie. 4/4/99 2:30am (on gap between standard and daylight time) is standard time or daylight? koushi.takahashi@japan 1999-09-21 GregorianCalendar has problems on daylight saving time transitions at the both cases. Closing this as a duplicate of 4312621. masayoshi.okutsu@Eng 2000-02-15
21-09-1999