Expose language, locale, and timezone info

[sunfishcode]

It would be good for WASI to be able to expose the information needed to implement the POSIX LANG, LC_*, and TZ environment variables.

One option would be to literally forward these environment variables through WASI's environment-variable system, however we'll likely want this information in programs which don't otherwise use environment variables, so we should consider a different API -- WASI libc could translate it into the environment variables for compatibility if needed.

[sbc100]

Are you saying you are worried about adding the cost of getenv + __environ to programs that just need the to know the timezone?

Seems unfortunate given that we have the mechanism in place already to use environment variables.
But I guess size in important?

If there are enough features that use environment variables like then then cost of having an environment at all will at least be amortized, and the more new APIs we design to replace erstwhile environment variables the less we benefit from the amortization.

[sunfishcode]

Environment variables in general aren't a great fit for shared-nothing linking.

Applications don't have any way of indicating up front which environment variables they need, so we tend to implicitly pass more than is needed, which needlessly leaks information.

Also, environment variables are limited to strings, so they aren't typed. They tend to get used to pass around path strings, which also makes them tend to implicitly depend on a shared filesystem view, which we can support with compatibility mechanisms, but it weakens the "shared-nothing" part of shared-nothing linking.

We can continue to support environment variables for compatibility with existing code, but it's worth thinking about whether we can avoid having essential functionality depend on environment variables in general, so that embeddings and applications which wish to avoid using environment variables altogether can do so without missing out.

[sbc100]

OK so our stance is generally "We don't like environment variables in WASI for a number of reasons".
So we will avoid them within WASI itself, but allow users to use them for legacy purposes if they wish?

I think that makes sense. We might want to document that somewhere.

[sunfishcode]

#192 briefly mentions this stance on environment variables.

[complexspaces]

👋 Hey there, has there been any further thinking on support for this feature? It recently came up on 1Password/sys-locale#18 where we had to hardcode None in the locale fetching implementation for the wasi target family for the time being.