New submission from Humberto Diogenes humberto@digi.com.br:
On some systems, datetime.strftime() accepts a %s format string that returns epoch / UNIX timestamp, but this behavior is not documented at http://docs.python.org/library/datetime.html
Python 2.7 (r27:82508, Jul 3 2010, 21:12:11) [GCC 4.0.1 (Apple Inc. build 5493)] on darwin Type "help", "copyright", "credits" or "license" for more information.
import datetime datetime.datetime.now().strftime('%s')
'1295376929'
---------- assignee: docs@python components: Documentation messages: 126481 nosy: docs@python, hdiogenes priority: normal severity: normal status: open title: Undocumented option for datetime.strftime: %s versions: Python 2.7
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue10938 _______________________________________
R. David Murray rdmurray@bitdance.com added the comment:
As you say, "on some systems". The variation is documented, and the documented codes are documented as being just those required by the C standard.
---------- nosy: +r.david.murray resolution: -> invalid stage: -> committed/rejected status: open -> closed type: -> behavior
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue10938 _______________________________________
Humberto Diogenes humberto@digi.com.br added the comment:
David, as discussed on the IRC channel: maybe we could just add pointers to the OS-specific docs. Something like:
""" If you want to use platform-specific format strings, search for strftime in your OS documentation (`man strftime` on POSIX systems).
Linux: http://www.kernel.org/doc/man-pages/online/pages/man3/strftime.3.html
Mac OS: http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPa... """
----------
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue10938 _______________________________________
R. David Murray rdmurray@bitdance.com added the comment:
All right, I'll open it back up for that suggestion (I've changed the title accordingly) and let the docs folks decide. The most useful link would be one to the relevant Windows documentation, since that's the hardest one to find.
Although this scheme avoids the problem of having to maintain a list of 'extra' format codes, it does have one of the same problems that doing so would have: the supported codes may change from OS version to OS version, and do we maintain the links accordingly? The mitigating factor is that I don't think the supported codes do change much.
---------- resolution: invalid -> stage: committed/rejected -> needs patch status: closed -> open title: Undocumented option for datetime.strftime: %s -> Provide links to system specific strftime/ptime docs type: behavior -> feature request versions: +Python 3.1, Python 3.2
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue10938 _______________________________________
Mark Lawrence added the comment:
@Humberto could you provide a patch for this?
---------- nosy: +BreamoreBoy versions: +Python 3.4, Python 3.5 -Python 3.1, Python 3.2
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue10938 _______________________________________
Changes by Chandan kumar chkumar246@gmail.com:
---------- pull_requests: +119
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue10938 _______________________________________
Changes by Nick Coghlan ncoghlan@gmail.com:
---------- nosy: +ncoghlan
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue10938 _______________________________________
Changes by Mark Lawrence breamoreboy@gmail.com:
---------- nosy: -BreamoreBoy
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue10938 _______________________________________
Berker Peksag added the comment:
I agree with Jim's review comment at https://github.com/python/cpython/pull/155#pullrequestreview-22646534
Those links will quickly get outdated and I'm sure that we will get reports like "this link doesn't work for my $PLATFORM $PLATFORM_VERSION".
I suggest to close this as 'rejected'.
---------- nosy: +berker.peksag stage: needs patch -> patch review versions: +Python 3.6, Python 3.7 -Python 3.4
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue10938 _______________________________________
Xiang Zhang added the comment:
I agree with Berker and Jim here. I think the current doc is clear enough so mark this as rejected. :-(
---------- nosy: +xiang.zhang resolution: -> rejected stage: patch review -> resolved status: open -> closed
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue10938 _______________________________________
-
Berker Peksag -
Chandan kumar
-
Humberto Diogenes
-
Mark Lawrence
-
Nick Coghlan
-
R. David Murray
-
Xiang Zhang