illumos: set default timezone info path

[AustinWise]

Empirically, this is where these files live on OpenIndiana and SmartOS (global zone and Joyent-branded zones). This also the documented location for illumos and Solaris. (Thanks for the pointers to man pages Tarek!)

This makes this test pass:

dotnet xunit.console.dll System.Runtime.Tests.dll -method "Tests.System.TimeProviderTests.TestSystemProviderWithTimeZone"

If you don't have the fix in this PR, you can also make this test pass by setting the TZDIR environmental variable to /usr/share/lib/zoneinfo/ .

Contributes to #34944

[tarekgh]

I have confirmed that both Solaris and Illumos used the /usr/share/lib/zoneinfo/ for the time zone files.

https://www.illumos.org/man/5/timezone and https://support.oracle.com/knowledge/Sun%20Microsystems/1011541_1.html#aref_section23

So, the change looks good here.

I am wondering, would it make sense instead of ifdef that for different system to introduce a fallback path to the time zones folder? I mean let GetTimeZoneDirectory return the time zones path in addition to fallback path too. Then pass these two paths to the methods reading the time zones like ReadAllBytesFromSeekableNonZeroSizeFile?

I am suggesting that as I am not sure if we build the browser or WASM for Solaris or Illumos and use the embedded files which can point at wrong path at that time?

CC @lewing if he can advise regarding the WASM cases.

@am11 do you have any feedback about this PR?

[am11]

I wasn't able to run it myself as I'm currently on osx-arm64 (where x64 VMs are quite slow). I trust what @AustinWise has found. However, I would like to test it in Global Zone vs. non- Global Zone. Sometimes these system paths and properties vary in a virtualized zone vs. GZ. (not to be confused with timezones; zones in sunos are like containers in linux and jails in freebsd, virtualized sandbox environment)

I mean let GetTimeZoneDirectory return the time zones path in addition to fallback path too. Then pass these two paths to the methods reading the time zones like ReadAllBytesFromSeekableNonZeroSizeFile?

Sounds like a good idea. It can probably return two strings for now, something like:

-        private static string GetTimeZoneDirectory()
+        private static (string knownPath, string fallbackPath) GetTimeZoneDirectory()

[AustinWise]

Having a fallback system seems reasonable. I'll set this to a draft for now, and undraft when I have an implementation and testing strategy.

[AustinWise]

I have confirmed that both Solaris and Illumos used the /usr/share/lib/zoneinfo/ for the time zone files.

Thanks for the links. I also found a version of the Solaris documentation that does not require a support subscription: https://docs.oracle.com/cd/E88353_01/html/E37852/timezone-5.html

I am suggesting that as I am not sure if we build the browser or WASM for Solaris or Illumos and use the embedded files which can point at wrong path at that time?

Looking at Directory.Build.props, it looks only one of TARGET_ILLUMOS, TARGET_SOLARIS, TARGET_WASI, and TARGET_BROWSER can be defined at one time. So this change should not effect the paths used on WASI and browser to lookup time zone info. Similarly, the embedded time zone info paths are hard-coded here. The embedded files themselves from the System.Runtime.TimeZoneData Nuget package. So this PR should not change the names of embedded files.

Considering the case of running a WASI app on an illumos system, this change should not have a negative effect. See UseEmbeddedTzDatabase in TimeZoneInfo.Unix.NonAndroid.cs. UseEmbeddedTzDatabase is true when TZDIR variable is NOT set. When UseEmbeddedTzDatabase is true and an embedded time zone file cannot be found, the code does not fall back to reading from the file system. When TZDIR is set, UseEmbeddedTzDatabase will be false and the value returned from GetTimeZoneDirectory() will be the value of TZDIR. Therefore, the fact that DefaultTimeZoneDirectory is incorrect for illumos should not effect a WASI app running on illumos.

Given all of the above, I'm not sure if change the code to probe multiple directories is worth it. There are already several fallbacks for probing different directories (example). Adding more fallbacks would further complicate the code and testing, for a scenario I'm not sure exists in the wild (non-standard timezone info path). And there is already the TZDIR workaround for people on non-standard systems.

Given the above, I'm going to un-draft this with the existing, simple implementation. Please let me know if I overlooked a case where the fallback would be valuable.

However, I would like to test it in Global Zone vs. non- Global Zone.

For what it's worth, I confirmed the location in the OpenIndiania global zone, the SmartOS global zone, and a Joyent-branded zone on SmartOS. I have not tried other distributions or zone brands.

[tarekgh]

@AustinWise thanks for your effort. The current change is ok. I am wondering if there is any other Linux based system using /usr/share/lib/zoneinfo/ and we are not aware of. The fallback can just make it work without any further changes. But I am ok to proceed with the current change for now and watch out if we see the issue again, we can consider the fallback at that time.

I'll wait for @am11 if he has any more comments and then we can merge the change.

[am11]

I have not tried other distributions or zone brands.

GZ is not recommended to be used for development purposes and using non-GZ zones is a common practice. In SmartOS, GZ doesn't even persists data and config by default and even if you alter the RO-ness, it has resource limitations. OmniOS made it simpler for the cloud but we are targeting generic SunOS. To get result from a neutral zone, you can create a base-64-lts zone, e.g. https://gist.github.com/am11/5f1702de2ce5474670da4e4604856891 (I pieced it together from an old stash).

[AustinWise]

Here are some different configurations to confirm the location of zone info in, with a checkmark indicating whether or not I have tested it:

• SmartOS
  • Global zone (20240701T205528Z)
  • Joyent-branded zone (base-64-lts 23.04 , though in Joyent-brand zones /usr is a lofs mount from the global zone 20240701T205528Z)
• OpenIndiana
  • global zone
  • ipkg-banded zone
  • nlipkg-branded zone
• Omni OS
  • global zone
  • ipkg-brand zone
  • lipkg-brand zone
  • sparse-brand zone
• tribblix
  • global zone
  • sparse zone
  • whole-root zone
  • The other three brand types (Alternate-root, Partial-root, and Alien-root) seem like less common configurations that are variations on the other two brand type.

Are there other distributions or zone brands I should try?

[am11]

Are there other distributions or zone brands I should try?

I think having tested on generic 64-bit base is fine. When linux distros running in a zone, we don't expect dotnet(1) to run cross OS (each OS has a separate ELF binary). Thanks for testing. Looks good to me!

ps - if you could keep a zone on OpenIndiana or SmartOS for future testing, that would be great to rule out any doubts.

[AustinWise]

I confirmed that this change is compatible with several other illumos distributions and zone brands. I updated the above table with the extra testing.

I am wondering if there is any other Linux based system using /usr/share/lib/zoneinfo/ and we are not aware of.

From what I can gleam from code search, AIX might also use this path. I don't see obvious evidence of a Linux distribution also using this path.

ps - if you could keep a zone on OpenIndiana or SmartOS for future testing, that would be great to rule out any doubts.

Will do, I'll add an OpenIndiana zone to my primary SmartOS zone testing environment.

[tarekgh]

Thanks @AustinWise, this is very helpful!