Changes between Initial Version and Version 7 of Ticket #28911


Ignore:
Timestamp:
Jan 13, 2018, 11:13:31 PM (7 years ago)
Author:
Stephen James
Comment:

The three Linux distributions available for WSL at present are Ubuntu 16.04, openSUSE 42.3, and SUSE Linux Enterprise Server 12. Having tested on all three, the issue is only present on WSL when running openSUSE (i.e. there doesn't seem to be any issues on Ubuntu and SLES).

On openSUSE only: 

$ ls /usr/share/zoneinfo
Msft

Msft is in all, but it is the only thing in openSUSE.

​here is where Django tries to verify the timezone and would raise a ValueError if /usr/share/zoneinfo exists, but doesn't contain anything for the specified timezone.

Upon further investigation, I stumbled across ​this, specifically:

Apparently, /usr/share/zoneinfo is missing from a (minimal) openSUSE installation...

I assume this is why none of the other timezones are there (Microsoft seemingly still adds theirs regardless, hence why /usr/share/zoneinfo/Msft and hence /usr/share/zoneinfo would still exist).

Installing the timezone package (zypper install timezone), as the aforementioned link suggests, will add them, which would allow Django to not fail on other time zones. I would suggest using that as a fix for the reporter and anyone else with a similar issue.

If there is any desire to make any changes to Django itself for this issue, then I'd suggest changing the validation attempts to further determine if that folder can be relied on.

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #28911

    • Property Component Error reporting → Utilities
    • Property Easy pickings unset
    • Property Owner set to nobody
    • Property Cc Sergey Fedoseev Stephen James added
    • Property Triage Stage Unreviewed → Accepted
    • Property Summary Django dependency pytz does not recognize Msft time zone within Windows Subsystem for Linux → Add support for the Msft time zone required on Windows Subsystem for Linux running openSUSE
    • Property Type Bug → Cleanup/optimization

  • Ticket #28911 – Description

    initial v7  
    1 Under Windows Subsystem for Linux (I was using openSUSE), the only available time zone is `Msft`, which uses settings that are set on the Windows side. This is not a valid time zone in pytz. In the process of reporting an error thrown by a bug in my code, Django tried to normalize the time zone provided in the project settings by passing it through pytz. pytz then complains that the time zone is unknown. Somewhat amusingly, this error is also caught by Django and goes through the same code path, quickly hitting the recursion limit.
     1Under Windows Subsystem for Linux, the only available time zone on openSUSE is `Msft`, which uses settings that are set on the Windows side. This is not a valid time zone in pytz. In the process of reporting an error thrown by a bug in my code, Django tried to normalize the time zone provided in the project settings by passing it through pytz. pytz then complains that the time zone is unknown. Somewhat amusingly, this error is also caught by Django and goes through the same code path, quickly hitting the recursion limit.
    22
    33See below for a significant part of the stack trace. My temporary solution was to change
Back to Top