harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [testing] first M6 candidate (r653525) testing status.
Date Thu, 22 May 2008 07:50:36 GMT
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 <junjie0122@gmail.com> 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 <alexei.fedotov@gmail.com>:
>
>> 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 <junjie0122@gmail.com> 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 <stepan.mishura@gmail.com>:
>> >
>> >> 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

Mime
View raw message