Skip to content
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

python: Handle massively negative initial zoneinfo entries. #166

Closed
wants to merge 1 commit into from

Conversation

Projects
None yet
1 participant
@ijc
Copy link
Contributor

ijc commented Jul 30, 2018

Some zoneinfo files contain such "big bang hack" entries as a workaround for a
bug, this was recently reverted upstream but such files are still around in the
wild (e.g. Ubuntu 14.04, current Debian testing). Some info on this can be
found in:

eggert/tz@83c119f

With this a:

from MythTV import datetime
import time
tnow = time.time()
print datetime.fromtimestamp(tnow).strftime("%Y%m%d%H%M%S %z")

Now produces the correct time. To reproduce I needed to run with
TZ=Europe/Vienna since I am in GMT/BST. Prior to this fix when running in
during Northern hemisphere daylight savings time (i.e. today) the code would
produce timezone of +0100 instead of the correct +0200. Similarly with
TZ=Americ/Los_Angeles an incorrect -0800 becomes -0700 with the fix.

The change only ignores initial entries of the bad for, since it would be
unexpected to see them once we have seen a transition for the "modern era"
(which I define as "something time.gmtime is happy with").

python: Handle massively negative initial zoneinfo entries.
Some zoneinfo files contain such "big bang hack" entries as a workaround for a
bug, this was recently reverted upstream but such files are still around in the
wild (e.g. Ubuntu 14.04, current Debian testing). Some info on this can be
found in:

eggert/tz@83c119f

With this a:

    from MythTV import datetime
    import time
    tnow = time.time()
    print datetime.fromtimestamp(tnow).strftime("%Y%m%d%H%M%S %z")

Now produces the correct time. To reproduce I needed to run with
`TZ=Europe/Vienna` since I am in GMT/BST. Prior to this fix when running in
during Northern hemisphere daylight savings time (i.e. today) the code would
produce timezone of +0100 instead of the correct +0200. Similarly with
`TZ=Americ/Los_Angeles` an incorrect -0800 becomes -0700 with the fix.

The change only ignores initial entries of the bad for, since it would be
unexpected to see them once we have seen a transition for the "modern era"
(which I define as "something time.gmtime is happy with").
@ijc

This comment has been minimized.

Copy link
Contributor Author

ijc commented Jul 30, 2018

@ijc

This comment has been minimized.

Copy link
Contributor Author

ijc commented Sep 3, 2018

Merged as ea500ae via the ticket.

@ijc ijc closed this Sep 3, 2018

@ijc ijc deleted the ijc:python-timezone-bindings-fix-for-lmt branch Sep 3, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.