Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
/etc/timezone is not a symlink - breaks .NET TimeZoneInfo API #3109
Microsoft Windows [Version 10.0.16299.309]
CoreFX relies on /etc/timezone being a symlink to work properly.
On Kali under WSL
Linux FLORIPA 4.4.0-43-Microsoft #1-Microsoft Wed Dec 31 14:42:53 PST 2014 x86_64 GNU/Linux
The same program gives different results on macOS and Linux:
On macOS 10.12.2
Darwin Brunos-MacBook-Pro.local 17.4.0 Darwin Kernel Version 17.4.0: Sun Dec 17 09:19:54 PST 2017; root:xnu-4570.41.2~1/RELEASE_X86_64 x86_64
On CentOS 7
The correct timezone information should be returned like exampled above with CentOS (outside WSL) and macOS.
This is discussed in #856. The issue here is that by default we add private timezone data that reflects Windows settings (timezone file is written as needed when a WSL instance is started). Normally when you setup timezone information (e.g. sudo dpkg-reconfigure tzdata) it creates a symlink to the appropriate tzdata file. This is so common that many tools, setup scripts, etc. have taken a dependency on it. Apparently not a lot of people are creating private timezone files. The easiest fix is just to setup standard timezone information. This means you will decouple from the Windows timezone information, but for most scenarios this is fine -- you will just need to adjust timezone information inside of WSL manually as needed, but this will not be that surprising for many *nix users.
Thanks for your quick reply!
Although I can fix my own instance, the code I'm writing (which depends on TimeZoneInfo.Local) is part of a NuGet library which is used in a variety of applications and platforms.
Any application running on WSL (I'm hoping there'll be many) will end up with the wrong behaviour.
I believe this is an issue and should be solved somehow. If it's decided that there is no way WSL can resolve this, perhaps the CoreFX team would consider having a special handling for WSL, having support to whatever way Windows passes on the value to Linux.
I do believe
I think it would be ok to symlink /etc/localtime, but /etc/timezone I am less confident of. The original implementation of our private timezone information did add a /etc/timezone, but it broke when tzdata was updated (if I recall the update script used the contents, assuming they were written by tzdata). So we backed off to the bare minimum update of /etc/localtime (and no symlinks). I am not sure if just updating /etc/localtime to a symlink would be of any value, but it would certainly be something we could do, were it to be beneficial.
referenced this issue
Apr 17, 2018
Per manual pages it seems reasonable to make
@Brian-Perkins,@pjanotti at least in build 17134, I noticed that
I think all mention of symlinking