This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author catherine
Recipients belopolsky, brian.curtin, catherine, skip.montanaro
Date 2010-08-26.17:48:07
SpamBayes Score 1.4797347e-10
Marked as misclassified No
Message-id <1282844890.06.0.732579415785.issue9650@psf.upfronthosting.co.za>
In-reply-to
Content
> There is the non-zero cost of keeping two copies of that bit of
> information in-sync with each other (and the code).

That's true, but how often do the strftime format codes change?  I'd be happy to personally volunteer to keep them in synch.  I suspect it would take me half an hour once or even twice per decade.

> I believe the reason is that time.strftime behavior is platform dependent, so "man strftime" is likely to produce more relevant documentation than "pydoc time.strftime".

So everything I've written with strftime is not cross-platform after all?  Eek.

Anyway, why couldn't the docstring do the same thing the Python docs do - report the ANSI codes, and mention that platform-specific variations are possible?

Alternately, simply including a suggestion to ``man strftime`` in the docs would be a good start, since I had no idea about that (and I doubt I'm the only one).  Of course, it's useless advice for Windows users.

> Note the source at one of these sites:

> "Source: Python’s strftime documentation." :-)

Of course - the point is that people are feeling enough pain in drilling down to the right place in the Python documentation that a convenient designated URL seems attractive by comparison.
History
Date User Action Args
2010-08-26 17:48:10catherinesetrecipients: + catherine, skip.montanaro, belopolsky, brian.curtin
2010-08-26 17:48:10catherinesetmessageid: <1282844890.06.0.732579415785.issue9650@psf.upfronthosting.co.za>
2010-08-26 17:48:08catherinelinkissue9650 messages
2010-08-26 17:48:07catherinecreate