[issue12750] datetime.strftime('%s') should respect tzinfo

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
versions: +Python 3.6 -Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12750] datetime.strftime('%s') should respect tzinfo

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
nosy: +shanmbic

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12750] datetime.strftime('%s') should respect tzinfo

[Robert Collins]

Robert Collins added the comment:

Moving this back to patch needed: the patch was reviewed by a committer and 
changes requested.

--
nosy: +rbcollins
stage: commit review -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12750] datetime.strftime('%s') should respect tzinfo

[Akira Li]

Akira Li added the comment:

issue22246 discusses the reverse: strptime('12345', '%s')

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12750] datetime.strftime('%s') should respect tzinfo

[akira]

akira added the comment:

> ``%s`` format 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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12750] datetime.strftime('%s') should respect tzinfo

[Mümin Öztürk]

Mümin Öztürk added the comment:

more tests and some documentation added.

--
Added file: http://bugs.python.org/file35816/strftime3.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12750] datetime.strftime('%s') should respect tzinfo

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

+t = datetime(1969, 1, 1, 0,0,0, 60, tzinfo=timezone.utc)

Please add spaces after commas.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12750] datetime.strftime('%s') should respect tzinfo

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

The patch should update documentation.

See 
https://docs.python.org/3.5/library/datetime.html#strftime-and-strptime-behavior

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12750] datetime.strftime('%s') should respect tzinfo

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

Could you, please add tests for non-fixed offset timezones?  There are several 
defined in datetimetester.py already.

--
versions: +Python 3.5 -Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12750] datetime.strftime('%s') should respect tzinfo

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

Here is the simpler demonstration of the "floor" behavior on Linux:

>>> from datetime import datetime
>>> datetime.fromtimestamp(-0.1).strftime('%s')
'-1'
>>> datetime.fromtimestamp(-1.1).strftime('%s')
'-2'
>>> datetime.fromtimestamp(0.1).strftime('%s')
'0'
>>> datetime.fromtimestamp(1.1).strftime('%s')
'1'

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12750] datetime.strftime('%s') should respect tzinfo

[akira]

akira added the comment:

> Can you explain why math.floor rather than builtin round is the correct 
> function to use?

To avoid breaking existing scripts that use `.strftime('%s')` on Linux, OSX,
see msg221385:

  >>> from datetime import datetime, timezone
  >>> dt = datetime(1969, 1, 1, 0,0,0, 60, tzinfo=timezone.utc)
  >>> '%d' % dt.timestamp()
  '-31535999'
  >>> round(dt.timestamp())
  -31535999
  >>> dt.astimezone().strftime('%s') # <-- existing behavior
  '-31536000'
  >>> '%d' % math.floor(dt.timestamp())
  '-31536000'
  >>> import calendar
  >>> calendar.timegm(dt.astimezone(timezone.utc).timetuple())
  -31536000

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12750] datetime.strftime('%s') should respect tzinfo

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

> rounding problem fixed with math.floor

Can you explain why math.floor rather than builtin round is the correct 
function to use?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12750] datetime.strftime('%s') should respect tzinfo

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

On the second thought, I don't think accepting this should be contingent on any 
decision with respect to strptime.

--
assignee:  -> belopolsky
stage: needs patch -> commit review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12750] datetime.strftime('%s') should respect tzinfo

[Mümin Öztürk]

Mümin Öztürk added the comment:

I added an improved patch according to akira's explanation for strftime and 
rounding problem.

--
Added file: http://bugs.python.org/file35785/strftime2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12750] datetime.strftime('%s') should respect tzinfo

[akira]

akira added the comment:

> I suspect that in the absence of %z, the most useful option would be to 
> return naive datetime in the local timezone, but that can be added later.

Naive datetime in the local timezone may lose information that is contained in 
the input timestamp:

  >>> import os
  >>> import time
  >>> from datetime import datetime
  >>> import pytz
  >>> os.environ['TZ'] = ':America/New_York'
  >>> time.tzset()
  >>> naive_dt = datetime(2014, 11, 2, 1, 30)
  >>> naive_dt.timestamp()
  1414906200.0
  >>> naive_dt.strftime('%s')
  '1414906200'
  >>> pytz.timezone('America/New_York').localize(naive_dt, 
is_dst=False).timestamp()
  1414909800.0
  >>> pytz.timezone('America/New_York').localize(naive_dt, 
is_dst=True).timestamp()
  1414906200.0
  >>> pytz.timezone('America/New_York').localize(naive_dt, is_dst=None)
  Traceback (most recent call last):
File "", line 1, in 
File "~/.virtualenvs/py3.4/lib/python3.4/site-packages/pytz/tzinfo.py", 
line 349, in localize
  raise AmbiguousTimeError(dt)
  pytz.exceptions.AmbiguousTimeError: 2014-11-02 01:30:00

1414906200 timestamp corresponds to 2014-11-02 01:30:00-04:00
but datetime(2014, 11, 2, 1, 30) along is ambiguous -- 
it may correspond to both 1414906200 and 1414909800 if local timezone is 
America/New_York.

It would be nice if datetime.strptime() would allow the round-trip whatever the 
local timezone is:

  >>> ts = '1414906800'
  >>> datetime.strptime(ts, '%s').strftime('%s') == ts

it is possible if strptime() returns timezone-aware datetime object.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12750] datetime.strftime('%s') should respect tzinfo

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

> It is not clear what the returned value for %s strptime should be:

I would start conservatively and require %z to be used with %s.  In this case, 
we can easily produce aware datetime objects.

I suspect that in the absence of %z, the most useful option would be to return 
naive datetime in the local timezone, but that can be added later.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12750] datetime.strftime('%s') should respect tzinfo

[akira]

akira added the comment:

*If* the support for %s strftime format code is added then it should
keep backward compatibility on Linux, OSX: it should produce an
integer string with the correct rounding.

Currently, datetime.strftime delegates to a platform strftime(3) for
format specifiers that are not described explicitly [1]:

> The full set of format codes supported varies across platforms,
> because Python calls the platform C library’s strftime() function,
> and platform variations are common. To see the full set of format
> codes supported on your platform, consult the strftime(3)
> documentation.

[1]: 
https://docs.python.org/3.4/library/datetime.html#strftime-strptime-behavior

%s is not defined in C, POSIX but is already defined on Linux, BSD [2]
where `datetime.now().strftime('%s')` can print an integer timestamp.

>  %sis replaced by the number of seconds since the Epoch, UTC (see
>  mktime(3)).

[2]: http://www.openbsd.org/cgi-bin/man.cgi?query=strftime

Unsupported format code is *undefined behavior* (crash, launch a
missile is a valid behavior) otherwise.

Support for additional codes on some platforms is explicitly mentioned
in datetime docs therefore %s behavior shouldn't change if it is
well-defined on a given platform i.e., `datetime.now().strftime('%s')`
should keep producing an integer string on Linux, BSD.

- old code: `aware_dt.astimezone().strftime('%s')`
- proposed code: `aware_dt.strftime('%s')` (all platforms)

'%d' produces the wrong rounding on my machine:

  >>> from datetime import datetime, timezone
  >>> dt = datetime(1969, 1, 1, 0,0,0, 60, tzinfo=timezone.utc)
  >>> '%d' % dt.timestamp()
  '-31535999'
  >>> dt.astimezone().strftime('%s')
  '-31536000'

`math.floor` could be used instead:

  >>> '%d' % math.floor(dt.timestamp())
  '-31536000'

There is no issue with the round-trip via a float timestamp for
datetime.min...datetime.max range on my machine. `calendar.timegm`
could be used to avoid floats if desired:

  >>> import calendar
  >>> calendar.timegm(dt.astimezone(timezone.utc).timetuple())
  -31536000

Note: dt.utctimetuple() is not used to avoid producing the wrong
result silently if dt is a naive datetime object; an exception is
raised instead.

The result is equivalent to `time.strftime('%s',
dt.astimezone().timetuple())` (+/- date/time range issues).

---

It is not clear what the returned value for %s strptime should be:
naive or timezone-aware datetime object and what timezone e.g.,

- old code: `datetime.fromtimestamp(int('-31536000'), timezone.utc)`
- proposed code: `datetime.strptime('-31536000', '%s')`

The result is an aware datetime object in UTC timezone.

--
nosy: +akira

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12750] datetime.strftime('%s') should respect tzinfo

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

I would like to hear from others on this feature.  One concern that I have is 
whether it is wise to truncate the fractional seconds part in '%s'.  Also, if 
we support '%s' in strftime we should probably support it in strptime as well.

--
nosy: +haypo, tim.peters

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12750] datetime.strftime('%s') should respect tzinfo

[Mümin Öztürk]

Mümin Öztürk added the comment:

I made a patch for datetime.strftime('%s'). it takes tzinfo into consideration.


>>> datetime.datetime(1970,1,1).strftime("%s")   
'-7200'

>>> datetime.datetime(1970,1,1, tzinfo=datetime.timezone.utc).strftime("%s")
'0'

datetime.date still behave as naive datetime.datetime
>>> datetime.date(1970,1,1).strftime("%s")
'-7200'

--
keywords: +patch
nosy: +mumino
Added file: http://bugs.python.org/file27231/strftime.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12750] datetime.strftime('%s') should respect tzinfo

[Santoso Wijaya]

Changes by Santoso Wijaya :


--
nosy: +santa4nt

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12750] datetime.strftime('%s') should respect tzinfo

[Daniel O'Connor]

Daniel O'Connor  added the comment:

On 17/08/2011, at 12:42, Alexander Belopolsky wrote:
> Alexander Belopolsky  added the comment:
> 
>> it would appear the problem lies with strftime()
> 
> Yes, strftime('%s') ignores tzinfo at the moment.  This is not a bug. Support 
> for '%s' format code is incidental and not documented in Python.
> 
> Nevertheless I think this is a good feature request.  I am changing the title 
> to make it more explicit.

OK thanks!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12750] datetime.strftime('%s') should respect tzinfo

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

> it would appear the problem lies with strftime()

Yes, strftime('%s') ignores tzinfo at the moment.  This is not a bug. Support 
for '%s' format code is incidental and not documented in Python.

Nevertheless I think this is a good feature request.  I am changing the title 
to make it more explicit.

--
components: +Extension Modules
keywords: +easy
stage: committed/rejected -> needs patch
title: datetime.datetime how to correctly attach a timezone to an existing 
naive datetime -> datetime.strftime('%s') should respect tzinfo
versions:  -Python 2.7, Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com