TzdbCompiler does not work on .NET Core 5.0, requires .NET 3.1

[Brian Park]

Hi,

I searched this mailing list and the GitHub issues, but didn't see anything related. My issue is that the TzdbCompiler does not run on .NET 5.0, but requires .NET 3.1. See below for error message. Can this be fixed? The Noda Time library itself seems to run fine on .NET 5.0, but not the compiler.

The workaround is to install both .NET 5.0 and .NET 3.1, which works fine on my dev machines, but I would like to avoid installing both into my Docker container at runtime (since GitHub Actions does not allow custom Docker images on their public infrastructure).

I'm happy to file an Issue on GitHub for tracking purposes

Brian

Environment:

* OS version:

    * Ubuntu 20.04 (Linux Mint 20 below, but same error encountered on Ubuntu 20.04)

* .NET version:

    * .Net Core 5.0.3

    * Installed using  https://docs.microsoft.com/en-us/dotnet/core/install/linux-ubuntu

* Noda Time Version:

    * Latest from GitHub

    * git clone g...@github.com:nodatime/nodatime.git

Error Message:

```

$ dotnet run \
        -p /home/brian/dev/nodatime/src/NodaTime.TzdbCompiler/NodaTime.TzdbCompiler.csproj \
        -- \
        -s https://data.iana.org/time-zones/releases/tzdata2021a.tar.gz \
        -w /home/brian/dev/nodatime/data/cldr/windowsZones-38-1.xml \
        -o tzdata2021a.nzd
It was not possible to find any compatible framework version
The framework 'Microsoft.NETCore.App', version '3.1.0' was not found.
  - The following frameworks were found:
      5.0.3 at [/usr/share/dotnet/shared/Microsoft.NETCore.App]

You can resolve the problem by installing the specified framework and/or SDK.

The specified framework can be found at:
  - https://aka.ms/dotnet-core-applaunch?framework=Microsoft.NETCore.App&framework_version=3.1.0&arch=x64&rid=linuxmint.20-x64
make: *** [Makefile:18: tzdata2021a.nzd] Error 150
```

[Jon Skeet]

I'd be happy to take a pull request for this, so long as it didn't make it any more long-winded to run normally. (I can't remember what the default behavior is if you specify multiple target frameworks.)

It's worth noting that I don't normally expect developers to run the compiler themselves anyway - is there any reason you're doing that rather than using the pre-build NZD files available from nodatime.org?

Jon

--

---
You received this message because you are subscribed to the Google Groups "Noda Time" group.
To unsubscribe from this group and stop receiving emails from it, send an email to noda-time+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/noda-time/b8599e66-834d-448e-ab5d-9299a0f50eb8n%40googlegroups.com.

[Brian Park]

Thanks for the quick reply.

I'm interesting in running TzdbCompiler directly so that I can use Noda Time in a Continuous Integration pipeline, to run my validation tests as soon as a new IANA TZDB version drops, instead of waiting for a new release of Noda Time. Once that works well, I want to point the TzdbCompiler directly at the unreleased TZDB files at https://github.com/eggert/tz, and run the CI on the unreleased TZDB to catch errors before a new release is created. (It looks like TzdbCompiler just needs a small tweak to ignore the missing Version.)

With regards to a PR to fix this, do you have a pointer where I should start? Because I started using C# and .NET just 4 days ago... Translating from Java to C# was relatively straightforward, but I have basically no knowledge of the .NET environment (I find it hard enough to just track the terminology: ".NET Core", ".NET Standard", ".NET Framework"??).

Brian

[Jon Skeet]

On Fri, 12 Mar 2021 at 15:43, Brian Park <br...@xparks.net> wrote:

Thanks for the quick reply.

I'm interesting in running TzdbCompiler directly so that I can use Noda Time in a Continuous Integration pipeline, to run my validation tests as soon as a new IANA TZDB version drops, instead of waiting for a new release of Noda Time.

Are you aware that typically a new .nzd file is published on https://nodatime.org within a few hours of the announcement of new data, and a new release of Noda Time alongside that? If you ever need to wait more than 12 hours, that's almost certainly because there's something in the data which is causing a problem for the TzdbCompiler. That won't help with your next aim, admittedly.

 

Once that works well, I want to point the TzdbCompiler directly at the unreleased TZDB files at https://github.com/eggert/tz, and run the CI on the unreleased TZDB to catch errors before a new release is created. (It looks like TzdbCompiler just needs a small tweak to ignore the missing Version.)

 

Right... that sounds okay, but I wouldn't want to end up with more work due to issues found within the unreleased data, which might then be reverted again.

With regards to a PR to fix this, do you have a pointer where I should start? Because I started using C# and .NET just 4 days ago... Translating from Java to C# was relatively straightforward, but I have basically no knowledge of the .NET environment (I find it hard enough to just track the terminology: ".NET Core", ".NET Standard", ".NET Framework"??).

Well you could try specifying multiple frameworks in the project file, with <TargetFrameworks> instead of <TargetFramework>. The frameworks should be semi-colon-separated (so <TargetFrameworks>netcoreapp3.1;net5.0</TargetFrameworks>).

I don't know off-hand what that will do in terms of running without specifying a framework.

Jon

[Brian Park]

On Friday, March 12, 2021 at 7:49:00 AM UTC-8 Jon Skeet wrote:

Are you aware that typically a new .nzd file is published on https://nodatime.org within a few hours of the announcement of new data, and a new release of Noda Time alongside that? If you ever need to wait more than 12 hours, that's almost certainly because there's something in the data which is causing a problem for the TzdbCompiler. That won't help with your next aim, admittedly.

No I did not know that. That's a great response time. But it would be ideal if my CI pipeline did not depend on a Noda Time release. It is just another extra human step between the source of truth (the IANA TZDB files) and my validation tests. Just to give you a small example where extra steps can cause problems: The NZD repository (https://nodatime.org/tzdb/index.txt) does not contain the 2020f release (https://data.iana.org/time-zones/releases/), probably because 2020f did not contain any changes to the data files. But my CI process would have triggered on the 2020f release, and would have failed.

Once that works well, I want to point the TzdbCompiler directly at the unreleased TZDB files at https://github.com/eggert/tz, and run the CI on the unreleased TZDB to catch errors before a new release is created. (It looks like TzdbCompiler just needs a small tweak to ignore the missing Version.)

 

Right... that sounds okay, but I wouldn't want to end up with more work due to issues found within the unreleased data, which might then be reverted again.

Just to give you more context, (I didn't want to include too much unnecessary details in my initial post), I'm less interested in validating the *data* from the TZDB, but validating the *algorithms*. I have a Time Zone library targeted towards resource constrained environments. By resource constrained, I mean ~32kB of flash, ~2kB of RAM, using 8-bit or 32-bit processors. My library encodes the ~386 zones from TZDB into about 25kB. My algorithms consume another ~10kB . I want to use Noda Time as a reference, to validate my library's algorithms against Noda Time's algorithms. As of TZDB 2021a, the two libraries agree with each other across all 386 zones, for all DST transitions from the year 1974 until 2050. So if TZDB reverts back a ZONE or RULE change, it doesn't matter for my purposes. I just care about how the algorithms handle the new transition rules.

With regards to a PR to fix this, do you have a pointer where I should start? Because I started using C# and .NET just 4 days ago... Translating from Java to C# was relatively straightforward, but I have basically no knowledge of the .NET environment (I find it hard enough to just track the terminology: ".NET Core", ".NET Standard", ".NET Framework"??).

Well you could try specifying multiple frameworks in the project file, with <TargetFrameworks> instead of <TargetFramework>. The frameworks should be semi-colon-separated (so <TargetFrameworks>netcoreapp3.1;net5.0</TargetFrameworks>).

I don't know off-hand what that will do in terms of running without specifying a framework.

Thanks, "TargetFrameworks" is just the hint that I needed. I can Google that, and learn about how .NET handles these things.

Brian

[Jon Skeet]

Ah... now we know that you're interested in validation, I'd suggest you have a look at https://github.com/nodatime/tzvalidate

While you may still want to run TzdbCompiler yourself, you could potentially use the rest of the code in that repo (and the file format) to make validation simpler and validate against other sources. That's what I use when running TzdbCompiler to make sure that Noda Time agrees with zic.

Jon

--

---
You received this message because you are subscribed to the Google Groups "Noda Time" group.
To unsubscribe from this group and stop receiving emails from it, send an email to noda-time+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/noda-time/8f1960d7-27c3-4206-b932-32a908b9d5ebn%40googlegroups.com.

[Jon Skeet]

I've just tried this myself, and under .NET 5.0 it expects to use nullable reference types by default, so there's a bit of work still to do there.

Bryan, could you file a feature request on GitHub? I doubt that I'll be able to get to this before Easter I'm afraid, but you never know when I might just find some time down the back of the sofa...

Jon

[Brian Park]

Yes, I noticed those errors. I created a PR while this is fresh on my mind, before I context switch to the next thing on my plate. I think I fixed the errors. Sent https://github.com/nodatime/nodatime/pull/1619. Thanks for the pointer to https://github.com/nodatime/tzvalidate, I will put that on my list to check out.