add cross-platform support for %s strftime-format code

[DanielOConnor]

BPO	12750
Nosy	@tim-one, @abalkin, @vstinner, @rbtcollins, @bitdancer, @4kir4, @pganssle, @AdamWill
Files	strftime.patch: patch for strftime("%s") strftime2.patch: rounding problem fixed with math.floor strftime3.patch: more tests and some documentation added.

^{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:

assignee = 'https://github.com/abalkin'
closed_at = None
created_at = <Date 2011-08-15.02:31:12.597>
labels = ['extension-modules', 'easy', 'type-feature', 'library']
title = 'add cross-platform support for %s strftime-format code'
updated_at = <Date 2018-07-05.15:45:46.504>
user = 'https://bugs.python.org/DanielOConnor'

bugs.python.org fields:

activity = <Date 2018-07-05.15:45:46.504>
actor = 'p-ganssle'
assignee = 'belopolsky'
closed = False
closed_date = None
closer = None
components = ['Extension Modules', 'Library (Lib)']
creation = <Date 2011-08-15.02:31:12.597>
creator = "Daniel.O'Connor"
dependencies = []
files = ['27231', '35785', '35816']
hgrepos = []
issue_num = 12750
keywords = ['patch', 'easy']
message_count = 29.0
messages = ['142095', '142129', '142130', '142131', '142150', '142190', '142244', '142245', '142249', '142250', '170808', '221353', '221385', '221386', '221602', '221606', '221620', '221622', '221868', '221872', '221873', '221875', '221877', '222030', '222047', '225643', '247372', '270533', '313176']
nosy_count = 13.0
nosy_names = ['tim.peters', 'belopolsky', 'vstinner', 'rbcollins', 'r.david.murray', 'santoso.wijaya', 'akira', 'bignose', "Daniel.O'Connor", 'mumino', 'shanmbic', 'p-ganssle', 'adamwill']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue12750'
versions = ['Python 3.6']

Linked PRs

• gh-56959: Add cross-platform support for %s strftime-format code #155964

[DanielOConnor]

It 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.

[bitdancer]

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]

On 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\>

---

[bitdancer]

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]

On 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 UTC

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)

----------
resolution: -> invalid
stage: -> committed/rejected
status: open -> closed

---

Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue12750\>

---

[bitdancer]

OK. At a minimum there is a doc issue here, so I'm reopening.

[abalkin]

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]

On 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 -ujr date +%s
Wed 17 Aug 2011 01:54:59 UTC
[ur 11:24] ~ >date -ujr 1313511831
Tue 16 Aug 2011 16:23:51 UTC

i.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 :)