runtime: IsDaylightSavingTime_CasablancaMultiYearDaylightSavings fails on rhel.8

We have an internal CI server that does daily builds of corefx on rhel.8. Since 24 sept, System.Runtime.Tests is failing on IsDaylightSavingTime_CasablancaMultiYearDaylightSavings.

I haven’t looked further into this yet.

  pushd /home/tester/corefx/artifacts/bin/System.Runtime.Tests/netcoreapp-Unix-Debug
  /home/tester/corefx/artifacts/bin/testhost/netcoreapp-Linux-Debug-x64/dotnet exec --runtimeconfig System.Runtime.Tests.runtimeconfig.json xunit.console.dll System.Runtime.Tests.dll -xml testResults.xml -nologo -notrait category=nonnetcoreapptests -notrait category=nonlinuxtests -notrait category=IgnoreForCI -notrait category=OuterLoop -notrait category=failing 
  popd
  ===========================================================================================================
  ~/corefx/artifacts/bin/System.Runtime.Tests/netcoreapp-Unix-Debug ~/corefx/src/System.Runtime/tests
    Discovering: System.Runtime.Tests (method display = ClassAndMethod, method display options = None)
    Discovered:  System.Runtime.Tests (found 5372 of 5419 test cases)
    Starting:    System.Runtime.Tests (parallel test collections = on, max threads = 4)
      System.Tests.DateTimeOffsetTests.ToLocalTime_MaxValue [SKIP]
        Condition(s) not met: "IsMaxValuePositiveLocalOffset"
      System.Tests.TimeZoneInfoTests.IsDaylightSavingTime_CasablancaMultiYearDaylightSavings(dateTimeString: "1940-02-25T00:00:00.0000000Z", expectedDST: True, expectedOffsetString: "1:00:00") [FAIL]
      System.Tests.TimeZoneInfoTests.IsDaylightSavingTime_CasablancaMultiYearDaylightSavings(dateTimeString: "1940-11-20T00:00:00.0000000Z", expectedDST: True, expectedOffsetString: "1:00:00") [FAIL]
      System.Tests.TimeZoneInfoTests.IsDaylightSavingTime_CasablancaMultiYearDaylightSavings(dateTimeString: "1940-12-31T23:59:59.0000000Z", expectedDST: True, expectedOffsetString: "1:00:00") [FAIL]
      System.Tests.TimeZoneInfoTests.IsDaylightSavingTime_CasablancaMultiYearDaylightSavings(dateTimeString: "1941-01-01T00:00:00.0000000Z", expectedDST: True, expectedOffsetString: "1:00:00") [FAIL]
      System.Tests.TimeZoneInfoTests.IsDaylightSavingTime_CasablancaMultiYearDaylightSavings(dateTimeString: "1945-02-24T12:00:00.0000000Z", expectedDST: True, expectedOffsetString: "1:00:00") [FAIL]
      System.Tests.TimeZoneInfoTests.IsDaylightSavingTime_CasablancaMultiYearDaylightSavings(dateTimeString: "1945-11-17T01:00:00.0000000Z", expectedDST: True, expectedOffsetString: "1:00:00") [FAIL]
      System.Tests.TimeZoneInfoTests.IsDaylightSavingTime_CasablancaMultiYearDaylightSavings(dateTimeString: "1945-11-17T22:59:59.0000000Z", expectedDST: True, expectedOffsetString: "1:00:00") [FAIL]
        Test with the zone Africa/Casablanca and date 2/25/1940 12:00:00 AM failed
        Expected: True
        Actual:   False
        Stack Trace:
          /home/tester/corefx/src/System.Runtime/tests/System/TimeZoneInfoTests.cs(2361,0): at System.Tests.TimeZoneInfoTests.VerifyDST(TimeZoneInfo tz, DateTime dt, Boolean expectedDST)
          /home/tester/corefx/src/System.Runtime/tests/System/TimeZoneInfoTests.cs(1743,0): at System.Tests.TimeZoneInfoTests.IsDaylightSavingTime_CasablancaMultiYearDaylightSavings(String dateTimeString, Boolean expectedDST, String expectedOffsetString)
        Test with the zone Africa/Casablanca and date 11/20/1940 12:00:00 AM failed
        Expected: True
        Actual:   False
        Stack Trace:
          /home/tester/corefx/src/System.Runtime/tests/System/TimeZoneInfoTests.cs(2361,0): at System.Tests.TimeZoneInfoTests.VerifyDST(TimeZoneInfo tz, DateTime dt, Boolean expectedDST)
          /home/tester/corefx/src/System.Runtime/tests/System/TimeZoneInfoTests.cs(1743,0): at System.Tests.TimeZoneInfoTests.IsDaylightSavingTime_CasablancaMultiYearDaylightSavings(String dateTimeString, Boolean expectedDST, String expectedOffsetString)
        Test with the zone Africa/Casablanca and date 12/31/1940 11:59:59 PM failed
        Expected: True
        Actual:   False
        Stack Trace:
          /home/tester/corefx/src/System.Runtime/tests/System/TimeZoneInfoTests.cs(2361,0): at System.Tests.TimeZoneInfoTests.VerifyDST(TimeZoneInfo tz, DateTime dt, Boolean expectedDST)
          /home/tester/corefx/src/System.Runtime/tests/System/TimeZoneInfoTests.cs(1743,0): at System.Tests.TimeZoneInfoTests.IsDaylightSavingTime_CasablancaMultiYearDaylightSavings(String dateTimeString, Boolean expectedDST, String expectedOffsetString)
        Test with the zone Africa/Casablanca and date 1/1/1941 12:00:00 AM failed
        Expected: True
        Actual:   False
        Stack Trace:
          /home/tester/corefx/src/System.Runtime/tests/System/TimeZoneInfoTests.cs(2361,0): at System.Tests.TimeZoneInfoTests.VerifyDST(TimeZoneInfo tz, DateTime dt, Boolean expectedDST)
          /home/tester/corefx/src/System.Runtime/tests/System/TimeZoneInfoTests.cs(1743,0): at System.Tests.TimeZoneInfoTests.IsDaylightSavingTime_CasablancaMultiYearDaylightSavings(String dateTimeString, Boolean expectedDST, String expectedOffsetString)
        Test with the zone Africa/Casablanca and date 2/24/1945 12:00:00 PM failed
        Expected: True
        Actual:   False
        Stack Trace:
          /home/tester/corefx/src/System.Runtime/tests/System/TimeZoneInfoTests.cs(2361,0): at System.Tests.TimeZoneInfoTests.VerifyDST(TimeZoneInfo tz, DateTime dt, Boolean expectedDST)
          /home/tester/corefx/src/System.Runtime/tests/System/TimeZoneInfoTests.cs(1743,0): at System.Tests.TimeZoneInfoTests.IsDaylightSavingTime_CasablancaMultiYearDaylightSavings(String dateTimeString, Boolean expectedDST, String expectedOffsetString)
        Test with the zone Africa/Casablanca and date 11/17/1945 1:00:00 AM failed
        Expected: True
        Actual:   False
        Stack Trace:
          /home/tester/corefx/src/System.Runtime/tests/System/TimeZoneInfoTests.cs(2361,0): at System.Tests.TimeZoneInfoTests.VerifyDST(TimeZoneInfo tz, DateTime dt, Boolean expectedDST)
          /home/tester/corefx/src/System.Runtime/tests/System/TimeZoneInfoTests.cs(1743,0): at System.Tests.TimeZoneInfoTests.IsDaylightSavingTime_CasablancaMultiYearDaylightSavings(String dateTimeString, Boolean expectedDST, String expectedOffsetString)
        Test with the zone Africa/Casablanca and date 11/17/1945 10:59:59 PM failed
        Expected: True
        Actual:   False
        Stack Trace:
          /home/tester/corefx/src/System.Runtime/tests/System/TimeZoneInfoTests.cs(2361,0): at System.Tests.TimeZoneInfoTests.VerifyDST(TimeZoneInfo tz, DateTime dt, Boolean expectedDST)
          /home/tester/corefx/src/System.Runtime/tests/System/TimeZoneInfoTests.cs(1743,0): at System.Tests.TimeZoneInfoTests.IsDaylightSavingTime_CasablancaMultiYearDaylightSavings(String dateTimeString, Boolean expectedDST, String expectedOffsetString)
      System.Tests.DateTimeOffsetTests.ToLocalTime_MinValue [SKIP]
        Condition(s) not met: "IsMinValueNegativeLocalOffset"
      System.Tests.DateTimeOffsetTests.ToLocalTime_Ambiguous [SKIP]
        Condition(s) not met: "IsPacificTime"
      System.Tests.ArgIteratorTests.ArgIterator_GetNextArgType [SKIP]
        Condition(s) not met: "IsArgIteratorSupported"
      System.Tests.ArgIteratorTests.ArgIterator_GetRemainingCount_GetNextArg [SKIP]
        Condition(s) not met: "IsArgIteratorSupported"
    Finished:    System.Runtime.Tests
  === TEST EXECUTION SUMMARY ===
     System.Runtime.Tests  Total: 34299, Errors: 0, Failed: 7, Skipped: 5, Time: 13.603s

cc @omajid @RheaAyase

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 36 (34 by maintainers)

Commits related to this issue

Most upvoted comments

@eerhardt Can you reproduce with:

make TOPDIR=$HOME/tzdir DATAFORM=rearguard install

If so, this is being caused by the ‘rearguard’ data format. I found some information in the NEWS file and some in this blog.

This looks like the commit that adds this Casablanca negative DST change: https://github.com/eggert/tz/commit/8539a448ebc8897e40d62f16dc4d0ada3f07b3ca

I think I was able to repro this issue using a RHEL 8 docker image, and updating it to tzdata-2019c-1.el8.noarch. It appears we are having trouble with parsing the Casablanca tzfile, in particular the “futureTransitionsPosixFormat” string. Since we are throwing an exception trying to make the AdjustmentRules, TimeZoneInfo is falling back to disabling daylight savings time here:

https://github.com/dotnet/corefx/blob/4a7075f188b5777ccb519f2af9b8a284f4383357/src/Common/src/CoreLib/System/TimeZoneInfo.Unix.cs#L632-L644

Then, the returned TimeZoneInfo instance doesn’t have any AdjustmentRules - thus all DST is turned off.

The reason the exception is being thrown is because we can’t parse the futureTransitionsPosixFormat string. On my machine the string looks like:

<+00>0<+01>,0/0,J365/25

The troublesome part is that 0/0 right in the middle. According to http://man7.org/linux/man-pages/man3/tzset.3.html,

   n      This specifies the zero-based Julian day with n between 0 and 365.  February 29 is counted in leap years.

See this comment:

https://github.com/dotnet/corefx/blob/4a7075f188b5777ccb519f2af9b8a284f4383357/src/Common/src/CoreLib/System/TimeZoneInfo.Unix.cs#L1238-L1263

A potential spot-fix for this exact scenario would be to support n where n < 59. As long as the date isn’t past Feb 28, we are able to model this TransitionTime with our current design.

Also related to https://github.com/dotnet/corefx/issues/29192

Attaching the Africa/Casablanca file from my RHEL 8 machine: Casablanca.zip

Hi,Eric I am sorry to return your software later, thank you for the information provided, and have provided me with a lot of help.

1468987382@qq.com

From: Eric Erhardt Date: 2019-11-13 23:04 To: dotnet/corefx CC: zhangjie0819; Mention Subject: Re: [dotnet/corefx] IsDaylightSavingTime_CasablancaMultiYearDaylightSavings fails on rhel.8 (#42192) @zhangjie0819 - The best document I’ve found is the man pages http://man7.org/linux/man-pages/man5/tzfile.5.html http://man7.org/linux/man-pages/man3/tzset.3.html — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

I like the last idea you mentioned and I think wouldn’t be too much to check all places we use TransitionTime to ensure handling breaking cases.