UTC equivalent of time.mktime() ?

[Graham Ashton]

I have not been following, so pardon me if this has already been
suggested, but on a platform where you have 2.0 or later and strptime,
lt = time.mktime(time.strptime(sys.argv[1], '%d %b %Y'))
utoffset = time.mktime(time.gmtime(lt)) - lt
print lt - utoffset

Thanks for that.

I was using strptime() and mktime() to get seconds since the epoch in
localtime. I was trying to work out if I could do anything simpler than
... if time.daylight:
... return secs - time.timezone - time.altzone
... else:
... return secs - time.timezone

to get the seconds since the epoch into UTC. It's looking as though the
answer (in general) is "no".

[Mark McEahern]

[Graham Ashton]

I appreciate that I could (and thanks for the suggestion), but does this
really mean that via the standard library there is no easy way to
convert "1 Jan 1970" to 0 (i.e. string to seconds since epoch)?
Perhaps I should inspect the mxDateTime code...

Anyway, mxDateTime rocks. I don't know why it's not part of the standard
distribution.

Here's a fer instance on why you oughter use it:

Windows doesn't have strptime

cygwin:

$ python
Python 2.2 (#1, Dec 31 2001, 15:21:18)
[GCC 2.95.3-5 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.

import time
time.strptime("1 Jan 1970", "%d %b %Y")

Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: 'module' object has no attribute 'strptime'

plain win:

C:\Python22>python
Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.

import time
time.strptime("1 Jan 1970", "%d %b %Y")

Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: 'module' object has no attribute 'strptime'

linux:

$ python
Python 2.2.1 (#1, Apr 10 2002, 09:15:55)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

import time
time.strptime("1 Jan 1970", "%d %b %Y")

(1970, 1, 1, 0, 0, 0, 3, 1, 0)

mx.DateTime.DateTimeFrom("1 Jan 1970")

<DateTime object for '1970-01-01 00:00:00.00' at 816d7b8>

epoch = mx.DateTime.DateTimeFrom("1 Jan 1970")
epoch.ticks()

21600.0

You want that to say zero, right, no matter what the local time zone is?

Thinking about UTC vs. localtime always starts to hurt my head...

// m

[Graham Ashton]

mx.DateTime.utc().ticks()

I appreciate that I could (and thanks for the suggestion), but does this
really mean that via the standard library there is no easy way to
convert "1 Jan 1970" to 0 (i.e. string to seconds since epoch)?

Perhaps I should inspect the mxDateTime code...

[M.-A. Lemburg]

mx.DateTime.utc().ticks()

I appreciate that I could (and thanks for the suggestion), but does this
really mean that via the standard library there is no easy way to
convert "1 Jan 1970" to 0 (i.e. string to seconds since epoch)?
Perhaps I should inspect the mxDateTime code...

Depends on whether your C lib supports leap seconds or not.

See the mxDateTime code for details:
mxDateTime_AsGMTTicksWithOffset()

[Graham Ashton]

Sorry to perpetuate the time theme, but I'm hoping somebody will cast an
eye over the following for me.

I'm trying to work out how to convert dates specified as strings (e.g.
"1 Jan 1970") into seconds since the epoch in UTC (e.g. 0). In a fit of
stupidity I've got stuck on a UTC vs localtime issue. If I explain what
I've been doing you'll see what I mean.

My approach is as follows:

- use time.strptime() to convert the string into a time tuple

- use time.mktime() to convert the tuple into seconds since the epoch
(which is in localtime, for some God awful reason that continues to
elude me - why?)

- modify the epoch value according to the local time zone and DST
(which seems horridly hackish).

In code, it looks like this:

Python 2.2 (#2, Mar 11 2002, 13:24:00)
[GCC 2.95.3 20010315 (release)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

import time
s = "1 Jan 1970"
tup = time.strptime(s, "%d %b %Y")
tup

(1970, 1, 1, 0, 0, 0, 3, 1, 0)

secs = time.mktime(tup)
secs # (I'm in the UK)

-3600.0
... if time.daylight:
... return secs - time.timezone - time.altzone
... else:
... return secs - time.timezone
...

local2utc(secs)

0.0

I'm not convinced that a sensible implementation of time keeping
libraries would force me to go to the effort of writing local2utc() in
order to convert "1 Jan 1970" to 0, so suspect that I've missed
something rather large. ;)

Thanks.

P.S. I've tried getting strptime() to understand %Z in it's format
string, and specify the timezone in the initial date string, but it
can't do it (even though the docs state that it understands everything
that stftime() does). Is this a bug, or a platform dependent thing? (I
suspect the latter -- I'm on Linux).

[Mark McEahern]

Why not just use the mxDateTime library and just do something like this:

mx.DateTime.utc().ticks()

// mark

[Donn Cave]

Quoth Graham Ashton <gashton at cmedltd.com>:
| On Wed, 2002-04-17 at 17:11, Mark McEahern wrote:
|> Why not just use the mxDateTime library and just do something like this:
|>
|> mx.DateTime.utc().ticks()
|
| I appreciate that I could (and thanks for the suggestion), but does this
| really mean that via the standard library there is no easy way to
| convert "1 Jan 1970" to 0 (i.e. string to seconds since epoch)?

I have not been following, so pardon me if this has already been
suggested, but on a platform where you have 2.0 or later and strptime,
this might do that:

lt = time.mktime(time.strptime(sys.argv[1], '%d %b %Y'))
utoffset = time.mktime(time.gmtime(lt)) - lt
print lt - utoffset

Donn Cave, donn at u.washington.edu

[Donn Cave]

Quoth Graham Ashton <gashton at cmedltd.com>:
...
| I was using strptime() and mktime() to get seconds since the epoch in
| localtime. I was trying to work out if I could do anything simpler than
| this (in which two of the "-" signs should be "+" signs):
|
| >>> def local2utc(secs):
| ... if time.daylight:
| ... return secs - time.timezone - time.altzone
| ... else:
| ... return secs - time.timezone
|
| to get the seconds since the epoch into UTC. It's looking as though the
| answer (in general) is "no".

Yes, I mean, no.

Donn Cave, donn at u.washington.edu