harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Yu" <junjie0...@gmail.com>
Subject Re: [testing] first M6 candidate (r653525) testing status.
Date Mon, 12 May 2008 05:30:34 GMT
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
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message