Repository navigation
add cross-platform support for %s strftime-format code #56959
Description
Activity
DanielOConnor commented
on Aug 15, 2011 DanielOConnormannequinMannequinAuthorIt isn't possible to add a timezone to a naive datetime object which means that if you are getting them from some place you can't directly control there is no way to set the TZ.
eg pywws' DataStore returns naive datetime's which are in UTC. There is no way to set this and hence strftime seems to think they are in local time.
I can sort of see why you would disallow changing a TZ once set but it doesn't make sense to prevent this for naive DTs.
Also, utcnow() returns a naive DT whereas it would seem to be more sensible to return it with a UTC TZ.
In what way does 'replace' not satisfy your need to set the tzinfo?
As for utcnow, we can't change what it returns for backward compatibility reasons, but you can get a non-naive utc datatime by doing datetime.now(timezone.utc). (I must admit, however, that at least this morning I can't wrap my head around how that works based on the docs :(.
DanielOConnor commented
on Aug 15, 2011 DanielOConnormannequinMannequinAuthorOn 15/08/2011, at 23:39, R. David Murray wrote:
R. David Murray <rdmurray@bitdance.com> added the comment:
In what way does 'replace' not satisfy your need to set the tzinfo?
Ahh that would work, although it is pretty clumsy since you have to specify everything else as well.
In the end I used calendar.timegm (which I only found out about after this).
As for utcnow, we can't change what it returns for backward compatibility reasons, but you can get a non-naive utc datatime by doing ´
That is a pity :(
datetime.now(timezone.utc). (I must admit, however, that at least this morning I can't wrap my head around how that works based on the docs :(.
OK.. I am only using 2.7 so I can't try that :)
----------
nosy: +r.david.murray
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue12750\>
Ah. Well, pre-3.2 datetime itself did not generate *any* non-naive datetimes.
Nor do you need to specify everything for replace. dt.replace(tzinfo=tz) should work just fine.
DanielOConnor commented
on Aug 15, 2011 DanielOConnormannequinMannequinAuthorOn 16/08/2011, at 1:06, R. David Murray wrote:
R. David Murray <rdmurray@bitdance.com> added the comment:
Ah. Well, pre-3.2 datetime itself did not generate *any* non-naive datetimes.
Nor do you need to specify everything for replace. dt.replace(tzinfo=tz) should work just fine.
OK.
I did try this and it seems broken though..
In [19]: now = datetime.datetime.utcnow()In [21]: now.replace(tzinfo = pytz.utc)
Out[21]: datetime.datetime(2011, 8, 15, 22, 54, 13, 173110, tzinfo=<UTC>)In [22]: datetime.datetime.strftime(now, "%s")
Out[22]: '1313414653'In [23]: now
Out[23]: datetime.datetime(2011, 8, 15, 22, 54, 13, 173110)[ur 8:22] ~ >date -ujr 1313414653
Mon 15 Aug 2011 13:24:13 UTCi.e. it appears that replace() applies the TZ offset to a naive datetime object effectively assuming it is local time rather than un-timezoned (which is what the docs imply to me)
----------
resolution: -> invalid
stage: -> committed/rejected
status: open -> closed
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue12750\>
OK. At a minimum there is a doc issue here, so I'm reopening.
- changed the title
[-]datetime.datetime timezone problems[/-][+]datetime.datetime how to correctly attach a timezone to an existing naive datetime[/+]on Aug 16, 2011 i.e. it appears that replace() applies the TZ offset to a naive datetime
object effectively assuming it is local time rather than un-timezoned
(which is what the docs imply to me)I don't understand your issue. The replace method does not assume anything, it just replaces whatever fields you specify with new values. You can replace tzinfo just like any other field, year, month, day, etc while preserving the other fields. I think this is fairly well documented. I think what you are looking for is the astimezone() method which, however may not work well on naive datetime instances simply because a naive instance may be ambiguous in presence of DST. However, if you start with an aware UTC datetime, you should be able to use astimezone() to convert to any local TZ.
DanielOConnor commented
on Aug 17, 2011 DanielOConnormannequinMannequinAuthorOn 17/08/2011, at 10:30, Alexander Belopolsky wrote:
Alexander Belopolsky <alexander.belopolsky@gmail.com> added the comment:
> i.e. it appears that replace() applies the TZ offset to a naive datetime
> object effectively assuming it is local time rather than un-timezoned
> (which is what the docs imply to me)I don't understand your issue. The replace method does not assume anything, it just replaces whatever fields you specify with new values. You can replace tzinfo just like any other field, year, month, day, etc while preserving the other fields. I think this is fairly well documented. I think what you are looking for is the astimezone() method which, however may not work well on naive datetime instances simply because a naive instance may be ambiguous in presence of DST. However, if you start with an aware UTC datetime, you should be able to use astimezone() to convert to any local TZ.
Hmm I see, it would appear the problem lies with strftime().
[ur 10:34] ~ >ipython-2.7
Python 2.7.2 (default, Aug 6 2011, 23:46:16)
Type "copyright", "credits" or "license" for more information.
IPython 0.10.2 -- An enhanced Interactive Python.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.In [48]: now = datetime.datetime.utcnow()
In [49]: nowtz = now.replace(tzinfo = pytz.utc)
In [50]: nowadl = now.replace(tzinfo = pytz.timezone('Australia/Adelaide'))
In [51]: now
Out[51]: datetime.datetime(2011, 8, 17, 1, 53, 51, 451118)
In [52]: nowtz
Out[52]: datetime.datetime(2011, 8, 17, 1, 53, 51, 451118, tzinfo=<UTC>)
In [53]: nowadl
Out[53]: datetime.datetime(2011, 8, 17, 1, 53, 51, 451118, tzinfo=<DstTzInfo 'Australia/Adelaide' CST+9:30:00 STD>)
In [54]: now.strftime("%F %r %s")
Out[54]: '2011-08-17 01:53:51 AM 1313511831'
In [55]: nowtz.strftime("%F %r %s")
Out[55]: '2011-08-17 01:53:51 AM 1313511831'
In [56]: nowadl.strftime("%F %r %s")
Out[56]: '2011-08-17 01:53:51 AM 1313511831'Wed 17 Aug 2011 01:54:52 UTC
[ur 11:24] ~ >date +%s
1313546093
[ur 11:24] ~ >date -ujrdate +%s
Wed 17 Aug 2011 01:54:59 UTC
[ur 11:24] ~ >date -ujr 1313511831
Tue 16 Aug 2011 16:23:51 UTCi.e. strftime disregards tzinfo and seems to treat the time as LT (I think).
It certainly doesn't behave the way I'd expect after using strftime(3) et al :)
16 remaining items
Could you, please add tests for non-fixed offset timezones? There are several defined in datetimetester.py already.
The patch should update documentation.
See https://docs.python.org/3.5/library/datetime.html#strftime-and-strptime-behavior
+ t = datetime(1969, 1, 1, 0,0,0, 600000, tzinfo=timezone.utc)
Please add spaces after commas.
mumino commented
on Jul 1, 2014 muminomannequinMannequinmore tests and some documentation added.
4kir4 commented
on Jul 1, 2014 4kir4mannequinMannequin%sformat code behaviour was undefined and incidental.strftime('%s') is not portable but it *is* supported on some
platforms i.e., it is *not* undefined and it is *not* incidental
on these platforms. datetime.strftime *delegates* to the platform
strftime(3) and some platforms do support %s format code. See the
quote from the datetime docs in msg221385.It would be preferable that datetime.strftime would reject format
codes that it doesn't support explicitly (like datetime.strptime
does) so that datetime.strftime were portable but that ship
has sailed.This issue could be titled: add cross-platform support for %s
strftime-format code (and fix its behavior (add support) for
timezone-aware datetime objects).---
If the implementation uses floats to get an integer result; it should
have tests for edge cases (datetime.min, datetime.max at least). I
don't see such tests, please, correct me if I'm wrong.4kir4 commented
on Aug 22, 2014 4kir4mannequinMannequinbpo-22246 discusses the reverse: strptime('12345', '%s')
Moving this back to patch needed: the patch was reviewed by a committer and changes requested.
Given that we have the .timestamp() method, I am not sure this would be a very useful feature, but maybe it is a way to eliminate an attractive nuisance.
If anyone is still interested in getting this in - please check with python-ideas.
- changed the title
[-]datetime.strftime('%s') should respect tzinfo[/-][+]add cross-platform support for %s strftime-format code[/+]on Jul 16, 2016 adamwill commented
on Mar 3, 2018 adamwillmannequinMannequinOn the "attractive nuisance" angle: I just ran right into this problem, and reported https://bugs.python.org/issue32988 .
As I suggested there, if Python doesn't try to fix this, I'd suggest it should at least *explicitly document* that using %s is unsupported and dangerous in more than one way (might not work on all platforms, does not do what it should for 'aware' datetimes on platforms where it *does* work). I think explicitly telling people NOT to use it would be better than just not mentioning it. At least for me, when I saw real code using it and that the docs just didn't mention it, my initial thought was "I guess it must be OK, and the docs just missed it out for some reason". If I'd gone to the docs and seen an explicit note that it's not supported and doesn't work right, that would've been much clearer and I wouldn't have had to figure that out for myself :)
For Python 2, btw, the arrow library might be a suitable alternative to suggest: you can do something like this, assuming you have an aware datetime object called 'awaredate' you want to get the timestamp for:
import arrow ts = arrow.get(awaredate).timestamp
and it does the right thing.
Metadata
Metadata
Assignees
Labels
Projects
- Status
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
Linked PRs