Hello Jim, My Outlook also updates CST to be equal to CDT during summer. I think behaving like RI is good. It is even better to understand why RI changes CST. The behavior is not mentioned in a list of known bugs [1], so it may be correct according to another set of rules.
I would suggest complementing your fix with another test case for summer dates. Thanks. [1] http://bugs.sun.com/bugdatabase/search.do?process=1&category=&subcategory=&type=&keyword=cst On Mon, May 12, 2008 at 9:30 AM, Jim Yu <[EMAIL PROTECTED]> wrote: > Hello Alexei, > Thank you for your further details about the time zones problem in America. > > It is a little more complicated than I thought earlier. According to [2] > as you list, some places will use CDT or EDT instead during summer to > activate > the daylight savings while CST and EST always keep a constant offset to UTC. > But in both RI and Harmony, there is no CDT and EDT timezones. For EST, it > is > identical with the one mentioned in [2] which always keep a constant offset > to UTC. > But for CST, it will use daylight savings during summer. I can't identify > the > specific date for the period that CST will activate the daylight savings > since > we relegate the calculation of timezone offset for current date (modified in > case > of daylight savings) to ICU. But I think it should be identical with RI (1). > When > the date is in the period that CST is using daylight savings in RI or > Harmony, > the difference between CST and EST is not an hour. > > (1) > [id=CST,offset=-21600000,dstSavings=3600000,useDaylight=true,startYear=0, > startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000, > startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1, > endTime=7200000,endTimeMode=0] > > > 2008/5/9 Alexei Fedotov <[EMAIL PROTECTED]>: > >> Hello Jim, >> Thank you for your patch! >> >> I'm trying to understand the statement from your JIRA report [1] >> addressing CST and EST with respect to a daylight savings adjustment. >> CST - Standard Time >> EST - Eastern Standard Time >> >> I think that the time zones which are adjusted to the daylight get >> different names: >> CDT - Central Daylight Time >> EDT - Eastern Daylight Time >> >> Moreover, all the listed time zones according to [2] have an official >> time zone offsets compared to the universal time (and a difference of >> the corresponding offsets is exactly one hour). Do you know a specific >> date when the difference between CST and EST is not an hour according >> to our GregorianCalendar? Calculated for this date, which time zone >> (CST or EST) offset to UTC does not match the official one? >> >> [1] http://issues.apache.org/jira/browse/HARMONY-5818 >> [2] http://www.timeanddate.com/library/abbreviations/timezones/na/edt.html >> and others >> >> >> On Fri, May 9, 2008 at 2:04 PM, Jim Yu <[EMAIL PROTECTED]> wrote: >> > Hi, >> > >> > About the org.apache.harmony.luni.tests.java.util.GregorianCalendarTest, >> > whether the two test cases below (1) (2) will pass or not depends on the >> > current date. >> > If current date is using daylight savings in "CST" while "EST" doesn't >> use >> > daylight >> > savings all the time, then the hour field of calendar for "CST" and >> "EST" >> > are the same, >> > the test cases will fail. Otherwise, "CST" is 1 hour before "EST", the >> test >> > cases will >> > succeed. So we should specify a fixed date for the calendar so as to >> make >> > the below >> > test cases behave unchangeably all the time. I've raised a JIRA and >> attached >> > a patch to it. >> > https://issues.apache.org/jira/browse/HARMONY-5818 >> > >> > 2008/5/7 Stepan Mishura <[EMAIL PROTECTED]>: >> > >> >> Hi all, >> >> >> >> Here is r653525 snapshot testing status. Briefly, there are several >> >> failures: some of them are intermittent (many in functional suite) >> >> and/or known issues (i.e there is JIRA for tracking, some of them are >> >> quite old). Also there are several new regressions (sigh, as usual >> >> :-() for investigation if they are blockers for M6 or not. >> >> >> >> Please add your comments and clarifications. >> >> >> >> 1) Classlib: >> >> >> >> Regressions on all platforms: >> >> org.apache.harmony.lang.management.MemoryPoolMXBeanImplTest >> >> >> >> >> >> org.apache.harmony.lang.management.tests.java.lang.management.MemoryPoolMXBeanTest >> >> org.apache.harmony.luni.tests.java.lang.ProcessBuilderTest >> >> org.apache.harmony.luni.tests.java.util.GregorianCalendarTest (2) >> >> >> >> New test: >> >> org.apache.harmony.unpack200.tests.ArchiveTest >> >> >> >> • Windows_x86: +1 failure >> >> Regression: >> >> org.apache.harmony.luni.tests.java.net.MulticastSocketTest >> >> >> >> • Linux_x86: +2 failures >> >> New test: >> >> >> org.apache.harmony.nio.tests.java.nio.MappedByteBufferTest#test_isload >> >> Regression: >> >> tests.api.java.security.PermissionCollectionTest >> >> >> >> • Linux_x86_64: +2 failures >> >> New test: >> >> >> org.apache.harmony.nio.tests.java.nio.MappedByteBufferTest#test_isload >> >> Regression: >> >> tests.api.java.security.PermissionCollectionTest >> >> >> >> 2) DRLVM tests: >> >> • Windows_x86_64: stress.Threads_srv (regression/crash) >> >> >> >> 3) EUTs: >> >> • Windows x86: 99.66% >> >> • Linux x86: 99.53% >> >> • Linux x86_64: 99.79% >> >> >> >> 4) Functional: >> >> >> >> Old regressions on all platforms: >> >> api.java.security.F_KeyFactoryTest_01 >> >> HARMONY-4857 : Bug in third-party component, regression introduced >> in M3 >> >> api.java.text.MessageFormat >> >> HARMONY-5430 : regression caused by migration to ICU >> >> api.java.util.jar.Manifest >> >> HARMONY-5473 : regression introduced by the fix >> >> api.java.beans.beancontext.BeanContextTest >> >> regression caused by changes in locale data >> >> >> >> New regressions on all platforms: >> >> api.java.beans.persistence (2) >> >> reg.vm.btest5625 >> >> >> >> • Windows_x86: + 1 failure >> >> Regression: >> >> api.java.io.ObjectOutputStream.writeObjectReadObject0030 >> >> >> >> Not regression (started to fail on M5): >> >> jit.HLO.devirt.Runtime.RuntimeExtend1 >> >> >> >> • Linux_x86: +8 failures >> >> Regression: >> >> java.math.F_BigIntegerMatrixMultiplyTest_01 >> >> api.java.rmi.basicexception >> >> api.java.rmi.basicregistry >> >> api.java.security.F_AlgorithmParametersTest_01 >> >> api.java.security.F_SecureRandomTest_02 >> >> api.java.security.F_SecureRandomTest_04 >> >> api.java.security.F_SecureRandomTest_05 >> >> >> >> Intermittent(?): >> >> api.java.net.ServerSocket >> >> >> >> • Windows_x86_64: +8 failures >> >> Regression since M4: >> >> jpda.jdwp.scenario.ST07 >> >> >> >> Not regression (started to fail on M5): >> >> jit.HLO.devirt.Runtime.RuntimeExtend1 >> >> >> >> Regression since M3,looked intermittent in M4-M5 but it stably fails >> >> jit.HLO.inline.ControlFlow.IfElse.IfElse1 >> >> reg.vm.btest5717 >> >> reg.vm.btest7214 >> >> >> >> Failed on M3 too, (Andrey said might be issue with the test) >> >> reg.vm.btest6353 >> >> >> >> Intermittent(?): >> >> api.java.io.ObjectOutputStream.writeObjectReadObject0003 >> >> api.java.io.ObjectOutputStream.writeObjectReadObject0021 >> >> reg.jit.btest4318 >> >> >> >> • Linux_x86_64: >> >> >> >> Regressions: >> >> api.java.math.F_BigIntegerMatrixMultiplyTest_01 >> >> api.java.rmi.basicexception >> >> api.java.rmi.basicregistry >> >> api.java.security.F_AlgorithmParametersTest_01 >> >> api.java.security.F_SecureRandomTest_02 >> >> api.java.security.F_SecureRandomTest_04 >> >> api.java.security.F_SecureRandomTest_05 >> >> reg.jit.btest6569 >> >> >> >> Regression since M4 >> >> jpda.jdwp.scenario.ST07 >> >> reg.jit.btest4318 >> >> >> >> Failed on M3 too, (Andrey said might be issue with the test) >> >> reg.vm.btest6353 >> >> >> >> Intermittent(?): >> >> api.java.math.F_BigIntegerExtEuclidTest_01 >> >> api.java.math.F_BigIntegerRSATest_01 >> >> api.java.io.ObjectOutputStream.writeObject0001 >> >> api.java.io.ObjectOutputStream.writeObject0003 >> >> api.java.io.ObjectOutputStream.writeObjectReadObject0003 >> >> api.java.io.ObjectOutputStream.writeObjectReadObject0007 >> >> api.java.io.ObjectOutputStream.writeObjectReadObject0011 >> >> api.java.io.ObjectOutputStream.writeObjectReadObject0015 >> >> api.java.io.ObjectOutputStream.writeObjectReadObject0016 >> >> api.java.io.ObjectOutputStream.writeObjectReadObject0022 >> >> api.java.io.ObjectOutputStream.writeObjectReadObject0028 >> >> api.java.io.ObjectOutputStream.writeObjectReadObject0040 >> >> api.java.io.ObjectOutputStream.writeObjectReadObject0041 >> >> reg.jit.btest1487 >> >> reg.vm.btest6008 >> >> reg.vm.btest7006 >> >> >> >> 5) Geronimo Unit Tests >> >> >> >> • Linux_x86: 2 failures >> >> org.apache.geronimo.tomcat.ContainerTest - intermittent(?) >> >> >> >> • Linux_x86_64: 2 failures >> >> org.apache.geronimo.timer.TransactionalThreadPooledTimerTest >> >> - intermittent(?) >> >> >> >> 6) Reliability: >> >> >> >> • Windows_x86: 2 failures >> >> api.net.DatagramTest - HARMONY-5531 >> >> api.net.SingleConnectTest - ??? >> >> >> >> • Linux_x86: 3 failures >> >> api.net.SingleConnectTest - ??? >> >> api.nio.charset.EncodingModesTest - intermittent(?) >> >> api.text.DecimalFormat_Locales - looked intermittent in M5 but it >> stably >> >> fails >> >> >> >> • Linux x86 64 bit: test host was down, rebooted >> >> >> >> 7) Stress: need investigation >> >> >> >> • Windows_x86: 4 failures >> >> >> >> Regression: >> >> exceptions.catcher.StackUnwindingManyObjectsTests >> >> >> >> Intermittent: >> >> classloader.NotSynchThreads.SupIntf >> >> exceptions.catcher.StackUnwindingTests >> >> jpda.jdwp.scenario.MIXED001 >> >> >> >> • Linux_x86: 4 failures >> >> Regression: >> >> exceptions.catcher.StackUnwindingManyObjectsTests >> >> >> >> HARMONY-5159 (failed on M4-M5 too): >> >> gc.frag.Fragmentation >> >> gc.frag.FragmentationFinalizer >> >> gc.frag.FragmentationReference >> >> >> >> • Windows_x86_64: 3 failures >> >> Regression: >> >> gc.mem.MemoryTest3 >> >> threads.StressThreads12Test >> >> >> >> Intermittent: >> >> classloader.MixThreads.LargeClassName >> >> >> >> • Linux_x86_64: 4 failures >> >> Regression: >> >> gc.mem.MemoryTest3 >> >> >> >> Intermittent: >> >> classloader.SynchThreads.LargeClassName >> >> exceptions.catcher.StackUnwindingTests >> >> gc.frag.FragmentationFinalizer >> >> >> >> 8) Struts & EGA: seems that both scenarios are broken >> >> >> >> Thanks, >> >> Stepan >> >> >> > >> > >> > >> > -- >> > Best Regards, >> > Jim, Jun Jie Yu >> > >> > China Software Development Lab, IBM >> > >> >> >> >> -- >> With best regards, >> Alexei >> > > > > -- > Best Regards, > Jim, Jun Jie Yu > > China Software Development Lab, IBM > -- With best regards, Alexei
