15

I want to see numpy datetime64 objects by my specified timezone.

>>> import numpy as np
>>> np.datetime64('2013-03-10T01:30:54')
numpy.datetime64('2013-03-10T01:30:54+0400')
>>> np.datetime64('2013-03-10T01:30:54+0300')
numpy.datetime64('2013-03-10T02:30:54+0400')

Python prints datetime objects always in UTC+0400 (it is my local timezone) even if I specify another timezone >>> np.datetime64('2013-03-10T01:30:54+0300'). Is there a way to force python print by UTC+0000 timezone?

I am using numpy 1.8.1 .

Samvel Hovsepyan
  • 639
  • 2
  • 6
  • 16
  • Why do you need to use numpy for this? Have you looked at [datetime](https://docs.python.org/3.4/library/datetime.html)? – Matt Johnson-Pint Aug 05 '14 at 16:25
  • Sure I know about python datetime objects, but historically I am getting datetime64 objects. I want to see datetimes in all timezones by the same way. – Samvel Hovsepyan Aug 06 '14 at 08:44

3 Answers3

8

Mentioned a few times in the numpy documentation:

The datetime object represents a single moment in time.

...

Datetimes are always stored based on POSIX time ...

So, internally a datetime64 is tracking a single integer, which represents a moment in time as a value since the UNIX epoch (1970-01-01) - not counting leap seaconds.

Therefore, time zones are not preserved. If you pass in a time zone offset, it will apply it to determine the correct UTC time. If you don't pass one, it will use the local machine's time zone. Regardless of input, on output it uses the local machine's time zone to project the UTC time to a local time with offset.

Community
  • 1
  • 1
Matt Johnson-Pint
  • 230,703
  • 74
  • 448
  • 575
  • @J.F.Sebastian - Technically, yes - that is correct. But many applications do not require such fine precision that leap seconds matter all that much. Still, I will update my wording. Thanks. – Matt Johnson-Pint Aug 31 '14 at 18:31
  • It is not about precision. It is about whether your program can handle possibly non-monotonous, non-continuous timestamps (btw, you should handle such cases even if there were no leap seconds -- `time.time()` may be set back that is why `time.monotonic()` exists for relative times). POSIX time doesn't count *elapsed* seconds since the Epoch (1970) though an application may consider it so i.e., an implementation can synchronize UTC and POSIX time (in some unspecified manner). See [Seconds Since the Epoch](http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html#tag_21_04_15) – jfs Aug 31 '14 at 18:45
  • I am confused as to how this answered the OP's question. Any insights on that? @J.F.Sebastian seems to have provided an answer to the question. – Dav Clark Jul 28 '15 at 21:02
  • @DavClark - I agree, but the OP has marked this answer. I cannot delete my answer unless the OP changes the accepted answer to J.F.'s. – Matt Johnson-Pint Jul 28 '15 at 22:06
6

Is there a way to force python print by UTC+0000 timezone?

You could call .item() that returns a naive datetime object that represents time in UTC on data in your example:

>>> import numpy
>>> numpy.__version__
'1.8.1'
>>> dt = numpy.datetime64('2013-03-10T01:30:54+0300')
>>> dt
numpy.datetime64('2013-03-10T02:30:54+0400')
>>> dt.item()
datetime.datetime(2013, 3, 9, 22, 30, 54)
>>> print(dt.item())
2013-03-09 22:30:54
jfs
  • 399,953
  • 195
  • 994
  • 1,670
3

You could always set the time zone before printing your datetime64 objects:

>>> import os, time, numpy
>>> os.environ['TZ'] = 'GMT'
>>> time.tzset()

>>> numpy.datetime64(0, 's')
numpy.datetime64('1970-01-01T00:00:00+0000')
Tom Grydeland
  • 31
  • 1
  • 3
    Have you tried it on Windows? Unrelated: `GMT` is ambiguous (is it UTC or Europe/London timezone in the winter?), use `UTC` instead. – jfs Sep 24 '15 at 17:08
  • This doesn't work at all. NumPy always prints in UTC. – John Zwinck Oct 16 '19 at 00:14
  • 1
    On `numpy.datetime64('1970-01-01T00:00:00+0000') ` I get a warning: `DeprecationWarning: parsing timezone aware datetimes is deprecated; this will raise an error in the future` – Dave X Oct 24 '19 at 15:30