13

datetime.now() and datetime.today() return time in UTC on my computer even though the documentation says they should return local time.

Here's the script I ran:

#!/usr/bin/python

import time
import datetime

if __name__ == "__main__":
   print(datetime.datetime.now())
   print(datetime.datetime.today())
   print(datetime.datetime.fromtimestamp(time.time()))

and here's the output:

2017-11-29 22:47:35.339914
2017-11-29 22:47:35.340399
2017-11-29 22:47:35.340399

The output of running date right after it is:

Wed, Nov 29, 2017  3:47:43 PM

Why is my installation returning time in UTC?
What can I do get those functions to return local time?

PS We are in MST, which is UTC-7.

PS 2 I realize there are methods to convert a UTC time to local time, such as those explained in Convert a python UTC datetime to a local datetime using only python standard library?. However, I am trying to understand the cause of the fundamental problem and not looking for a method to patch the problem in my own code.

In response to comment by @jwodder:

The output of executing

print(time.altzone)
print(time.timezone)
print(time.tzname)

is:

-3600
0
('Ame', 'ric')
JimHawkins
  • 4,843
  • 8
  • 35
  • 55
R Sahu
  • 204,454
  • 14
  • 159
  • 270
  • 1
    See: https://stackoverflow.com/questions/4563272/convert-a-python-utc-datetime-to-a-local-datetime-using-only-python-standard-lib – rassar Nov 29 '17 at 22:57
  • 1
    @rassar, thanks for the link. It's got useful info but doesn't answer the question I have. – R Sahu Nov 29 '17 at 23:04
  • 1
    Your system's timezone is likely set to UTC. What values do [`time.tzname` and friends](https://docs.python.org/3/library/time.html#timezone-constants) have? – jwodder Nov 29 '17 at 23:47
  • 1
    `date` shows me the timezone; if you do `date -R` what does that say? – Nick T Nov 29 '17 at 23:49
  • @NickT, `Wed, 29 Nov 2017 16:50:10 -0700`. – R Sahu Nov 29 '17 at 23:50
  • @jwodder, see the updated info in the question. – R Sahu Nov 29 '17 at 23:55
  • 4
    You timezone is definitely hosed. I am guessing the `'Ame', 'ric'` is the start of `America`. No clue how that happened. On my machine for `time.tzname` I get `('Pacific Standard Time', 'Pacific Daylight Time')`. You did not specify your OS, etc, but track down how the timezone is set on your system... – Stephen Rauch Nov 30 '17 at 04:45
  • @StephenRauch, thanks for your input. – R Sahu Nov 30 '17 at 16:47

3 Answers3

6

As you note in your answer, the TZ environment variable is the key here. On unix-type systems, this supports more "friendly" values like "US/Pacific" or, indeed, "America/Denver", but on Windows, it doesn't. Although it's not available on Windows, the documentation for the time.tzset function describes the format you'll need to set TZ in to get what you want. It's... not pretty. But it works:

C:\Users\zorb>set TZ=MST+07MDT,M3.2.0,M11.1.0
C:\Users\zorb>python.exe
>>> import time
>>> time.tzname
('MST', 'MDT')
>>> import datetime
>>> datetime.datetime.now()
datetime.datetime(2018, 2, 9, 16, 27, 7, 164062)

(This was at 15:27 in Pacific time.) The structure of this format is:

  • Standard time abbrevation (MST)
  • UTC offset of standard time, in hours (+07)
  • Daylight time abbreviation
  • When daylight time starts (see below)
  • When daylight time ends (see below)

The format for the start and end of daylight time is:

  • M (for "month-based")
  • Month number - 3/March or 11/November, in this case.
  • Week of the month - 1 through 5, meaning the 1st through 5th occurrence of the day named below.
  • Day of the week - 0 for Sunday through 6 for Saturday

There are also options to specify the time at which daylight time starts and ends (but it defaults to 02:00:00, so unnecessary in this case) and the offset for daylight time (but it defaults to 1 hour, so also not necessary).

(edit) Turns out this is actually a glibc feature, not directly a python one. More detailed info in the glibc docs.

Nathan Vērzemnieks
  • 5,495
  • 1
  • 11
  • 23
2

Initially, it appeared to be a problem caused by the use of cygwin.

The question at Cygwin shows UTC time instead of local time helped further isolate the problem to the value of the environment variable TZ in cygwin.

The updated script:

import time
import datetime

if __name__ == "__main__":
   print(datetime.datetime.now())
   print(datetime.datetime.today())
   print(datetime.datetime.fromtimestamp(time.time()))
   print(time.altzone)
   print(time.timezone)
   print(time.tzname)

Output when run under a Windows CMD shell with, where TZ is not set:

"D:\Program Files\Python35\python.exe" test.py

2017-11-30 09:39:47.236798
2017-11-30 09:39:47.236799
2017-11-30 09:39:47.236799
21600
25200
('Mountain Standard Time', 'Mountain Daylight Time')

Output when run under a cygwin bash shell with, where TZ is set to "America/Denver":

 /cygdrive/D/Program\ Files/Python35/python.exe test.py

2017-11-30 16:39:45.419884
2017-11-30 16:39:45.419884
2017-11-30 16:39:45.419884
-3600
0
('Ame', 'ric')

It's set to "America/Denver". When I executed

env TZ="" /cygdrive/D/Program\ Files/Python35/python.exe test.py

I got a more sensible output:

2017-11-30 09:56:08.643368
2017-11-30 09:56:08.643368
2017-11-30 09:56:08.643368
21600
25200
('Mountain Standard Time', 'Mountain Daylight Time')

When I set the environment variable TZ to "America/Denver" in the windows CMD shell, I get the same output as when run in the cygwin shell.

It's not clear to me how Python uses the environment variable TZ and what the correct values are for it.

R Sahu
  • 204,454
  • 14
  • 159
  • 270
  • 1
    Yet another reason I'll never use Cygwin. – Nick T Dec 07 '17 at 18:55
  • 1
    @NickT, cygwin turned out to be a red herring though. The real problem is that if the environment variable `TZ` is set, even just in CMD console, the problem is still there. That's a fundamental Python problem. – R Sahu Dec 07 '17 at 18:59
  • So you're using a non-Cygwin version of Python from a Cygwin shell? Then yes, the TZ conventions will most likely be incompatible. It would probably be best to use the Cygwin version of Python if you want it to understand Unix-style TZ convention. – Ove Feb 15 '18 at 14:02
  • @Ove, ideally, yes. However, sometimes that's not an option. – R Sahu Feb 15 '18 at 16:39
1

I think there is some odd behavior going on with things using the glibc time and timezone libraries on Windows. I started noticing this behavior in both python and emacs recently.

The best thing to do is probably to set TZ to the "ugly" version described in the best answer as that seems to fix issues in python and emacs and works correctly in cygwin as well.

Another workaround I tried is to make sure the TZ environment variable is NOT set. The following illustrates the problem around 10:18 New York time in python. I get similar results using either cygwin or CMD on Windows. Emacs illustrates the same problem using the current-time-string function suggesting it is a glibc issue or at least some library which both python and emacs are using. Interestingly the date command in cygwin gives the correct result with TZ set to "America/New York" but incorrect if TZ is unset.

Summary: some things (e.g., python, emacs) on Windows seem to not accept "America/New_York" for TZ while some things (e.g., cygwin) do accept it. Using something like EST+05EDT,M4.1.0,M10.5.0 for eastern time (or appropriate ugly equivalent) works.

$ echo $TZ
America/New_York

$ python -i
Python 3.6.4 |Anaconda, Inc.| (default, Jan 16 2018, 10:22:32) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> datetime.datetime.now()
datetime.datetime(2018, 5, 14, 15, 38, 6, 174073)
>>> datetime.datetime.now()
datetime.datetime(2018, 5, 14, 15, 38, 57, 141708)
>>> quit()

$ export TZ=

$ python -i
Python 3.6.4 |Anaconda, Inc.| (default, Jan 16 2018, 10:22:32) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> datetime.datetime.now()
datetime.datetime(2018, 5, 14, 10, 38, 41, 102117)
oxer
  • 975
  • 1
  • 10
  • 16