13

Is the epoch start time in Python independent of the platform (i.e. always 1/1/1970)?

Or is it platform dependent?

I want to serialize datetimes (with second accuracy) on various machines running Python, and be able to read them back on different platforms, possibly also using different programming languages (than Python). Is serializing epoch time a good idea?

kaalus
  • 4,475
  • 3
  • 29
  • 39
  • possible duplicate of [Is Python's time.time() timezone specific?](http://stackoverflow.com/questions/11845803/is-pythons-time-time-timezone-specific) – phihag Jan 06 '13 at 20:07
  • @phihag: your answer to the other question also answers this question but the question itself is not a duplicate. – jfs Jan 06 '13 at 20:29

5 Answers5

11

The documentation says:

To find out what the epoch is, look at gmtime(0).

I would interpret this to mean that no particular epoch is guaranteed.

See also this Python-Dev thread. That seems to confirm the notion that, in practice, the epoch is always assumed to be 1970/01/01, but that this is not explicitly guaranteed by the language.

The upshot of this is that, at least for Python, you're probably okay using epoch time unless you're dealing with strange and obscure platforms. For reading with non-Python tools, you're probably also okay, but to be extra sure you'd need to read the documentation those tools provide.

BrenBarn
  • 242,874
  • 37
  • 412
  • 384
  • So something [like this](http://msdn.microsoft.com/en-us/library/0z9czt0w%28v=vs.80%29.aspx)? – kojiro Jan 06 '13 at 20:15
  • @kojiro: Are you asking what `gmtime` means? It refers to the `gmtime` function in the Python `time` module. – BrenBarn Jan 06 '13 at 20:16
  • I was asking what that means at a lower level than that. `time.gmtime(0)` isn't informative – you just end up asking the same question about it. The library that Python is built on, be it CPython, Jython, IronPython – that is where the interesting definition of `gmtime()` is. – kojiro Jan 06 '13 at 20:19
3

Epoch time (unix time) is a standard term:

http://en.wikipedia.org/wiki/Unix_time

Unix time, or POSIX time, is a system for describing instances in time, defined as the number of seconds that have elapsed since midnight Coordinated Universal Time (UTC), 1 January 1970,[note 1] not counting leap seconds.[note 2] It is used widely in Unix-like and many other operating systems and file formats. It is neither a linear representation of time nor a true representation of UTC.[note 3] Unix time may be checked on some Unix systems by typing date +%s on the command line

That means if you use the epoch times through Python, it will be consistent across platforms. Your best bet for consistency is to use UTC in all cases.

jdi
  • 90,542
  • 19
  • 167
  • 203
  • What if Python will be running on a non-Unix system? – kaalus Jan 06 '13 at 20:08
  • @kaalus: It will still be consistant through python as an interface. – jdi Jan 06 '13 at 20:09
  • It’s still the same unix time. Just because there is “unix” in the name it does not mean that it’s only available on Unix systems. You are guaranteed to get a consistent result on all supported platforms. – poke Jan 06 '13 at 20:09
  • 2
    I don't believe this is correct. The documentation says: "Most of the functions defined in this module call platform C library functions with the same name. It may sometimes be helpful to consult the platform documentation, because the semantics of these functions varies among platforms." It may work on all platforms you care about, but it's not guaranteed to. – BrenBarn Jan 06 '13 at 20:10
  • @BrenBarn: yea probably True. It is consistant if you always base it on `gmtime(0)` per platform :-) I upvoted your answer. – jdi Jan 06 '13 at 20:16
1

time() would always return the time from epoch, look at the documentation.

Please note that Epoch is always the number of seconds since 1970, but since the clock on different machines are not the same - you'll might experience some problems.

Citation:

The epoch is the point where the time starts. On January 1st of that year, at 0 hours, the “time since the epoch” is zero. For Unix, the epoch is 1970. To find out what the epoch is, look at gmtime(0).

And:

time.time()¶

Return the time in seconds since the epoch as a floating point number. Note that even though the time is always returned as a floating point number, not all systems provide time with a better precision than 1 second. While this function normally returns non-decreasing values, it can return a lower value than a previous call if the system clock has been set back between the two calls.

(Both from Python documentation).

Yam Mesicka
  • 6,243
  • 7
  • 45
  • 64
  • 1
    It's true that different machines may have different clock times. Some workarounds for this include programming in some padding around the times so each machine has some give, and using systems like [NTP](http://www.ntp.org/) to ensure the clocks are reasonably close. – kojiro Jan 06 '13 at 20:10
  • Thanks kojiro, great info :) – Yam Mesicka Jan 06 '13 at 20:14
1

Micropython's epoch is 1/1/2000, see time() and utime.

lumbric
  • 7,644
  • 7
  • 42
  • 53
0

In Python pandas.to_datetime(), while the default is unix epoch origin, you can change it by providing your custom reference timestamp.

For example, 

pd.to_datetime(18081) #default unix epoch
Out: Timestamp('1970-01-01 00:00:00.000018081') #default is in nanosecond

pd.to_datetime(18081, unit='D')
Out: Timestamp('2019-07-04 00:00:00') #change unit of measure

You can change it to any reference date. Make sure the unit is reasonable. In example below, we set the origin to January 1, 1960. Note that this is default SAS date start date. 

pd.to_datetime(18081, unit='D',  origin='1960-1-1') #change to your reference start date
Out: Timestamp('2009-07-03 00:00:00')
Sarah
  • 1,854
  • 17
  • 18