Add globalization sample

[richlander]

Globalization invariant mode is a major part of our size optimization strategy, yet, we don't have much guidance on how to use it correctly. However, we do receive feedback about these topics. Also, we don't have great policies of when to install icu and tzdata. This sample will hopefully help inform that.

Related to #4413

[tarekgh]

Here is good example for the collation:

    CompareInfo turkishCompare = new CultureInfo("tr-TR").CompareInfo;
    Console.WriteLine(turkishCompare.Compare("i", "\u0130", CompareOptions.IgnoreCase)); // print 0 as "i" is equal to Turkish I "\u0130".
    
    CompareInfo englishCompare = new CultureInfo("en-US").CompareInfo;
    Console.WriteLine(englishCompare.Compare("i", "\u0130", CompareOptions.IgnoreCase)); // print -1 as "i" is not equal to Turkish I "\u0130" in non-Turkish cultures.

[richlander]

I like the Turkish I example. While it's not exactly obscure, it is also a bit of a novelty. I wonder if there are other cases we should cover. For example, if you were building an e-commerce app in Westerrn Europe or US, can you get away with globalization invariant mode? If not, what's an obvious example for why not?

[Clockwork-Muse]

For timezone specifically, we've had multiple issues in the main repository with people volume mounting /etc/localtime, and I feel like the mention of using /etc/timezone is going to get them to host-mount that (as opposed to using the TZ environment variable, which is what has been recommended previously).
That's for the extremely rare cases you actually want to run a server/container in a locale/zone in the first place, since in almost all cases the relevant locale/zone should be picked up from some referenced entity.

If we're dealing with just timezone data, there's all sorts of fun timezones with relatively recent "fun" adjustments, or quite unusual offsets that are lesser known in the western world.

[richlander]

I didn't know about the pattern to mount the directory. I can include that.

Yes, I am familiar with local time being an anti-pattern. The current text makes it sound like we're encouraging it, which isn't the intent. I can update that. People appear to be doing this (from my research), which led me to want to include it.

When the timezone file is mounted, what does it typically content? Is it the UTC value?

Thanks for the feedback. Appreciated.

[Clockwork-Muse]

Uh, no.
The recommendation, at least previously, has been to just add the TZ environment variable, not mount any host files:

docker run --rm -e TZ=$(cat /etc/timezone) mcr.microsoft.com/dotnet/aspnet:6.0-focal date

We especially don't want people mounting /etc/localtime, since that doesn't work. From a "best practices" standpoint, we likely also want to not encourage baking configuration into containers.

[tarekgh]

@richlander please don't use the mounting options. The issue dotnet/runtime#60469 has detailed discussions about that. In short, Most Linux systems do file system symbolic/hard linking to the zone files. If you are mounting any TZ file to the container, it will interfere with that and will start producing inconsistent results for the time conversions and reporting zone names. As @Clockwork-Muse mentioned, please use TZ environment variable to set the default time zone on the container. This is much cleaner and shouldn't cause any problem.

[tarekgh]

@richlander

I like the Turkish I example. While it's not exactly obscure, it is also a bit of a novelty. I wonder if there are other cases we should cover. For example, if you were building an e-commerce app in Westerrn Europe or US, can you get away with globalization invariant mode? If not, what's an obvious example for why not?

Here is a good example:

            // Å LATIN CAPITAL LETTER A WITH RING ABOVE is equal to 'A'  + '\u030A'  

            CompareInfo englishCompare = new CultureInfo("en-US").CompareInfo;
            Console.WriteLine(englishCompare.Compare("\u00C5", "A\u030A"));

[richlander]

@Clockwork-Muse Thanks for that it. It makes sense. In practice, what value would you expect in /etc/timezone from the host?

[Clockwork-Muse]

TZ should be set to one of the normal tzdb/IANA timezone identifiers, whatever you happen to pick (the example command previously was for somebody who wanted to use the host timezone, but for testing purposes you could/should pass anything).

In my case it's America/Los_Angeles. Wikipedia has a list, which you could also use to find some unusual zones.

[richlander]

ChatGPT knows all.

[Clockwork-Muse]

... using NTP to interface with the host's time seems a bit much (you'd have to set it at a server), and NTP doesn't handle timezones anyways. ChatGPT is wong.

If it was better, it would try to warn you away from setting timezone for the container in the first place.

[richlander]

Just saw your comment now, but I removed that extra info. Good now?

I very much appreciate the help!

[richlander]

You might want to take a look at this other PR, too @Clockwork-Muse . It is dealing with some of the same concepts.

#4413

[richlander]

I believe I have addressed all the feedback.

[richlander]

Fixed merge conflict with other PR.