[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

[Akira Li]

Akira Li added the comment:

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

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12750
___
___
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 rep...@bugs.python.org
http://bugs.python.org/issue12750
___
___
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 rep...@bugs.python.org
http://bugs.python.org/issue12750
___
___
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 rep...@bugs.python.org
http://bugs.python.org/issue12750
___
___
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 rep...@bugs.python.org
http://bugs.python.org/issue12750
___
___
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 rep...@bugs.python.org
http://bugs.python.org/issue12750
___
___
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 rep...@bugs.python.org
http://bugs.python.org/issue12750
___
___
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 rep...@bugs.python.org
http://bugs.python.org/issue12750
___
___
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 stdin, line 1, in module
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 rep...@bugs.python.org
http://bugs.python.org/issue12750
___
___
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 rep...@bugs.python.org
http://bugs.python.org/issue12750
___
___
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 rep...@bugs.python.org
http://bugs.python.org/issue12750
___
___
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 rep...@bugs.python.org
http://bugs.python.org/issue12750
___
___
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 rep...@bugs.python.org
http://bugs.python.org/issue12750
___
___
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 rep...@bugs.python.org
http://bugs.python.org/issue12750
___
___
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 rep...@bugs.python.org
http://bugs.python.org/issue12750
___
___
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 rep...@bugs.python.org
http://bugs.python.org/issue12750
___
___
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 santoso.wij...@gmail.com:


--
nosy: +santa4nt

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12750
___
___
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 alexander.belopol...@gmail.com 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 rep...@bugs.python.org
http://bugs.python.org/issue12750
___
___
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 dar...@dons.net.au added the comment:

On 17/08/2011, at 12:42, Alexander Belopolsky wrote:
 Alexander Belopolsky alexander.belopol...@gmail.com 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 rep...@bugs.python.org
http://bugs.python.org/issue12750
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com