Ticket #5812 (closed defect: fixed)

SVN Diffs for #5812

 

Opened 1 year ago

Last modified 4 months ago

ICU4J Calendar handles ambiguous local time differently from Java

Reported by: yoshito Assigned to: yoshito
Priority: major Milestone: 3.8.1
Component: time_calc Version: Current
Keywords: Cc:
Load: Xref: 5990
Java Version: Operating System:
Project (C/J): all Weeks: 0.4
Review: emmons

Description

At DST onset, the local time jumps forward. A time falls into this hole is ambiguous. With Sun Java Calendar implementation, the ambiguous time is interpreted as local standard time. For example, March 11, 2007 2:30AM in US Eastern time is interpreted as March 11, 2007 3:30AM EDT. However, ICU4J implementation interprets it as March 11, 2007 1:30 EST. The following code snipet illustrates the issue. This problem is also reproduced with ICU4C.

package com.ibm.icu.bugs;


import java.util.Date;
import java.util.Locale;

import java.text.DateFormat;
import java.util.Calendar;
import java.util.TimeZone;

//import com.ibm.icu.text.DateFormat;
//import com.ibm.icu.util.Calendar;
//import com.ibm.icu.util.TimeZone;


public class DSTTransition {
	public static void main(String[] args) {
		TimeZone tz = TimeZone.getTimeZone("America/New_York");
		Calendar cal = Calendar.getInstance(tz, Locale.US);
		cal.clear();
		cal.set(2007, Calendar.MARCH, 11, 2, 30);
		System.out.println(cal.get(Calendar.HOUR_OF_DAY) + ":" + cal.get(Calendar.MINUTE));
		System.out.println(cal.get(Calendar.DST_OFFSET) > 0 ? "DST" : "STD");
	}
}

Attachments

Change History

08/15/07 11:41:41 changed by yoshito

  • milestone changed from 3.8 to 4.0.

In Aug 15, 2007 ICU core project meeting, we agreed to fix this after 3.8 release.

# Ambiguous local time at DST onset (yoshito)

  1. Input to Calendar or to DateFormat parsing: 2007-03-11 2:30AM PT is interpreted as 2007-03-11 1:30AM PST
  2. Incompatible with Java - http://bugs.icu-project.org/trac/ticket/5812 - Java gives 2007-03-11 3:30AM PDT
  3. TimeZone#getOffset(long date, boolean local, int[] offsets) is used in Calendar implementation
  4. When date = <local milliseconds for 2007-03-11 2:30AM>, local = true, getOffset returns raw = <-8 hr> and dstsavings = <1 hr>. So getOffset for 2007-03-11 2:30AM in PT is in DST.
  5. date+offsets[0]+offsets[1] != UTC. If getOffset returns raw = <-8 hr> and dstsavigs = <0 hr>, then date+offsets[0]+offsets[1] == UTC is always true and Calender should work like Java.
  6. Same in ICU4C. See test cases showing ICU's behavior in http://source.icu-project.org/trac/browser/icu/trunk/source/test/intltest/dtfmttst.cpp#L1749
  7. Do we want to -
    1. change the calendar behavior and make it compatible with Java?
    2. change the behavior of getOffset(long, boolean, int[]) [this is not parallel with the JDK] or to add a new API to support the behavior (could be yet another option in the API which Markus recently proposed for ambiguous time support)?
  8. Consensus to make Calendar and DateFormat parsing behavior consistent with Java.
  9. We should check Olson localtime() behavior.
  10. Consensus that getOffset() and Calendar should agree on whether a point in time is DST. As result, don't change getOffset().
  11. Yoshito and Markus should revisit the recent getOffset() proposal and consider documentation or additional API (enum) to address the spring-forward non-existent times.
  12. Fix Calendar after ICU 3.8.

09/28/07 14:39:18 changed by yoshito

  • weeks changed from 0.2 to 0.4.

11/28/07 13:10:46 changed by yoshito

  • xref set to 5990.

11/28/07 13:24:13 changed by yoshito

  • status changed from new to assigned.
  • revw set to emmons.
  • milestone changed from 4.0 to 3.8.1.

The behavior was updated in both ICU4J and ICU4C. The fix was merged as a part of #5990.

01/04/08 12:05:50 changed by emmons

  • status changed from assigned to closed.
  • resolution set to fixed.

08/14/08 18:57:01 changed by anonymous

http://www.salewroughtiron.cn installing metal stair rails Interior stair handrail installing metal stair rails Interior stair handrail exterior baluster Glass wood stainless wrought CONTEMPORARY designs stairways aluminum modern log banister DECK outdoor price posts vinyl curved rails http://www.china-made-door.com.cn door gate http://www.beijing-door.cn wrought CONTEMPORARY designs stairways installing metal stair rails Interior stair handrail exterior baluster Glass wood stainless wrought CONTEMPORARY designs stairways aluminum modern log banister DECK outdoor price posts vinyl curved rails http://www.hebei-railings.cn aluminum modern log banister DECK outdoor price installing metal stair rails Interior stair handrail exterior baluster Glass wood stainless wrought CONTEMPORARY designs stairways aluminum modern log banister DECK outdoor price posts vinyl curved rails posts vinyl curved rails

09/11/08 23:10:27 changed by anonymous

documentation. KDE is by far larger and has so many different apps, which need screenshots and end user not dev/api docs, that more help is needed as long as the devs prefer to code than to write nice docs. And it is their choice to some degree imo. Technically interested but non-dev end users, which are plenty out there, are the users of and the best contributers to the docs, since they know what to write about. And they are certainly more than devschina tour I still prefer a wiki like approach since the php (or mysql) docs are very cluttered when you have to take their comments in account. On the other hand they are professionally maintained imho, since they are *much* better than KDE

Add/Change #5812 (ICU4J Calendar handles ambiguous local time differently from Java)




Anti spam check: