DateTime.Now started failing at 1am on Daylight Savings Time 3/10/2019

[richardschoen]

Last line of code in this section started blowing up at 1am Central on Daylight Savings Time. Technically it's probably not needed to convert DateTime.Now because the TZ environment variable set works, but I use similar code later in a directory list to convert date/time on files to local timezone and it works fine. The error seems to have something to do with using the custom TimeZoneInfo object against DateTime.Now at daylight savings time. You can't make this stuff up :-)

Using MONO SAVF - 10/14/18 Binary Snapshot. Been holding to this version for now.

Sample code you can copy to any C# console app and run. Last line will fail. I'm going to guess the problem self-resolves later on 3/10/2019 on by 3/11/2019 if it's daylight savings time related.

// Note: You MUST set up TZ before calling any date/time functions.
Environment.SetEnvironmentVariable("TZ", "America/Chicago");
Console.WriteLine("TimeZone: " + "America/Chicago");
Console.WriteLine("Current time once TimeZone TZ env variable set: " + DateTime.Now);

// Getting the current system timezone info.
TimeZoneInfo tz = TimeZoneInfo.Local;
Console.WriteLine("TimeZoneInfo.Local Offset:" + tz.BaseUtcOffset);
Console.WriteLine("DateTime.Now:" + DateTime.Now.ToString());

// Below line fails. It started causing errors on Daylight savings time day. 3/10/2019 at 1am.
// TODO - test this scenario at some point. See if it works the day after daylight savings. Might be a Mono date bug possibly ??
// DateTime.Now by itself seems to work though as does using the same timezone def against file attribute dates. Wierd.
Console.WriteLine("TimeonInfo.Local UTC Time:" + TimeZoneInfo.ConvertTime(DateTime.Now, tz).ToString());

C# stack error:
Unhandled Exception:
System.ArgumentException: dateTime parameter is an invalid time
at System.TimeZoneInfo.ConvertTime (System.DateTime dateTime, System.TimeZo
neInfo sourceTimeZone, System.TimeZoneInfo destinationTimeZone) [0x00074] in
<6a799ddc80574ae4a394013133ece9c2>:0
at System.TimeZoneInfo.ConvertTime (System.DateTime dateTime, System.TimeZo
neInfo destinationTimeZone) [0x0001d] in <6a799ddc80574ae4a394013133ece9c2>:0

at MonoDateTester1.Program.Main (System.String[] args) [0x0007e] in <44d426
0c30374da59dc80a0246a96acd>:0

[richardschoen]

Interestingly enough the error went away after jumping the IBMi clock forward to 3/10/2019 2:00am by changing QTIME system value. System QUTCOFFSET is -06:00 for CST. If you test, you should set your system at date of: 3/10/2019 via QDATE system value and set QTIME to 010000 for 1am.

[richardschoen]

One more test. Changed time to: 000000 and then 005900 and these both work. As soon as we hit 010000 the error occurs until the clock hits 020000. This error could bite anyone who is using DateTime.Now with a custom timezone on Daylight savings time day. Obscure, but true.

[NattyNarwhal]

i think it's due to these possible things, though I haven't tested them extensively:

• The zonefiles in the old packages are a bit stale (packaging newer ones in RPM is a "will do")

• PASE sets TZ automatically to a custom one contained entirely in TZ from *TIMZON objects. (as an alternative approach, one could teach Mono about the ILE time zone APIs, or generate IANA zonefiles from *TIMZON)

[richardschoen]

Should be easy to test, although only a use-case that fails twice per year for an hour :-)

However DateTime.Now should never be expected to fail.