New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

/etc/timezone is not a symlink - breaks .NET TimeZoneInfo API #3109

Open
bruno-garcia opened this Issue Apr 16, 2018 · 6 comments

Comments

Projects
None yet
5 participants
@bruno-garcia

bruno-garcia commented Apr 16, 2018

  • Your Windows build number: (Type ver at a Windows Command Prompt)

Microsoft Windows [Version 10.0.16299.309]

  • What you're doing and what's happening: (Copy&paste specific commands and their output, or include screen shots)

CoreFX relies on /etc/timezone being a symlink to work properly.
Calling TimeZoneInfo API gives the wrong output:

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

// .NET Core 2.0.6:
TimeZoneInfo.Local.DisplayName:                          GMT
TimeZoneInfo.Local.Id:                                   Msft/localtime

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

// .NET Core 2.0.6:
TimeZoneInfo.Local.DisplayName:                       GMT+01:00
TimeZoneInfo.Local.Id:                                Europe/Vienna

On CentOS 7
Linux centos-7.shared 3.10.0-693.5.2.el7.x86_64 #1 SMP Fri Oct 20 20:32:50 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

// .NET Core 2.0.6:
TimeZoneInfo.Local.DisplayName:                       Central European Standard Time
TimeZoneInfo.Local.Id:                                Europe/Vienna
  • What's wrong / what should be happening instead:

The correct timezone information should be returned like exampled above with CentOS (outside WSL) and macOS.

@Brian-Perkins

This comment has been minimized.

Show comment
Hide comment
@Brian-Perkins

Brian-Perkins Apr 16, 2018

Collaborator

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.

Collaborator

Brian-Perkins commented Apr 16, 2018

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.

@bruno-garcia

This comment has been minimized.

Show comment
Hide comment
@bruno-garcia

bruno-garcia Apr 16, 2018

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 /etc/timezone not being a symlink will end up giving other problems anyway so worth investing time in changing this approach.

bruno-garcia commented Apr 16, 2018

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 /etc/timezone not being a symlink will end up giving other problems anyway so worth investing time in changing this approach.

@fpqc

This comment has been minimized.

Show comment
Hide comment
@fpqc

fpqc Apr 16, 2018

MS could put their dynamic files in /wsl/ and symlink them, Brian?

fpqc commented Apr 16, 2018

MS could put their dynamic files in /wsl/ and symlink them, Brian?

@Brian-Perkins

This comment has been minimized.

Show comment
Hide comment
@Brian-Perkins

Brian-Perkins Apr 17, 2018

Collaborator

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.

Collaborator

Brian-Perkins commented Apr 17, 2018

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.

@pjanotti

This comment has been minimized.

Show comment
Hide comment
@pjanotti

pjanotti Jul 25, 2018

Member

Per manual pages it seems reasonable to make /etc/localtime a symlink as described above. So the quick procedure described on the man pages to get a timezone identifier is not available by default, of course one could use the workaround described at #1392 but things that use the symlink may have trouble on WSL while working just fine on Ubuntu.

Member

pjanotti commented Jul 25, 2018

Per manual pages it seems reasonable to make /etc/localtime a symlink as described above. So the quick procedure described on the man pages to get a timezone identifier is not available by default, of course one could use the workaround described at #1392 but things that use the symlink may have trouble on WSL while working just fine on Ubuntu.

@andyneff

This comment has been minimized.

Show comment
Hide comment
@andyneff

andyneff Sep 1, 2018

@bruno-garcia According to this line, /etc/localtime was expected to be a symlink, not /etc/timezone. Do you agree?

@Brian-Perkins,@pjanotti at least in build 17134, I noticed that /etc/localtime is already hardlinked to /usr/share/zoneinfo/Msft/localtime, and that /usr/share/zoneinfo/Msft/localtime is the file that wslhost. writes to while you run "Bash for Windows". In that case, I believe it is highly useful to make /etc/localtime symlink to /usr/share/zoneinfo/Msft/localtime as the original default behavior instead. This will benefit the many programs that expect /etc/localtime to be a symlink, mentioned here and in #1392). (Or course that won't have any affect on the TimeZoneInfo.Local.Id saying Msft/localtime.)

I think all mention of symlinking /etc/timezone is a typo.

andyneff commented Sep 1, 2018

@bruno-garcia According to this line, /etc/localtime was expected to be a symlink, not /etc/timezone. Do you agree?

@Brian-Perkins,@pjanotti at least in build 17134, I noticed that /etc/localtime is already hardlinked to /usr/share/zoneinfo/Msft/localtime, and that /usr/share/zoneinfo/Msft/localtime is the file that wslhost. writes to while you run "Bash for Windows". In that case, I believe it is highly useful to make /etc/localtime symlink to /usr/share/zoneinfo/Msft/localtime as the original default behavior instead. This will benefit the many programs that expect /etc/localtime to be a symlink, mentioned here and in #1392). (Or course that won't have any affect on the TimeZoneInfo.Local.Id saying Msft/localtime.)

I think all mention of symlinking /etc/timezone is a typo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment