classification
Title: external strftime for Python?
Type: enhancement Stage:
Components: Versions: Python 3.3
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: amaury.forgeotdarc, belopolsky, berker.peksag, cvrebert, eric.araujo, eric.smith, flox, gvanrossum, loewis, schmir, vstinner
Priority: normal Keywords: patch

Created on 2008-06-23 02:44 by skip.montanaro, last changed 2014-06-29 22:36 by belopolsky.

Files
File name Uploaded Description Edit
strftime.diff skip.montanaro, 2008-06-23 02:44
Messages (17)
msg68603 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2008-06-23 02:44
Back in April we had a thread on xmlrpclib's problematic handling of dates
before 1900:

    http://thread.gmane.org/gmane.comp.python.devel/93273/focus=93309

I'm still of the opinion that strftime() is the culprit and xmlrpclib is
just an innocent bystander.  Guido worried that to correct this we'd have 
to
implement strftime() from scratch.

I took a different approach and scouted around for an existing version of
strftime() which we could suck into the distribution.  I found a modified
version of the BSD 4.4 strftime which came with (I see to recall) Tcl.
The attached patch is against the py3k svn repo.  It passes all tests as
far as I can tell.

Also, see http://bugs.python.org/issue1777412 which appears to be related.
msg68604 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2008-06-23 02:47
Ummm...  I think I only modified timemodule.c.  datetimemodule.c
probably needs a tweak as well.  I need to get this off my desk though.
msg68606 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-06-23 03:54
So how does it work for non-English locales?
msg69092 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2008-07-02 13:42
Good question.  I don't claim that the strftime.c I found is complete
for our needs, only that we can avoid the "rewrite strftime from
scratch" problem Guido indicated.

S
msg75730 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2008-11-11 04:11
The issue #1777412 has a working patch (for Python 2.6) which allows 
year < 1900 in time.strftime() and datetime.datetime.strftime().
msg107168 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-06-06 00:29
What platforms have broken strftime and how badly is it broken there?

Is there a python version somewhere?  PyPy?
msg107315 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2010-06-08 11:34
PyPy also calls the platform's strftime().
msg111886 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2010-07-29 03:21
What about the licensing? That look like the BSD license *with* advertising clause...
msg111954 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-07-29 15:52
On Wed, Jul 28, 2010 at 11:22 PM, Guido van Rossum
<report@bugs.python.org> wrote:
..
> What about the licensing? That look like the BSD license *with*
> advertising clause...
>

I am not a lawyer and I am not intimately familiar with PSF policies,
but this license does not look too dissimilar to the profile module
license:

# Permission to use, copy, modify, and distribute this Python software
# and its associated documentation for any purpose (subject to the
# restriction in the following sentence) without fee is hereby
granted,
# provided that the above copyright notice appears in all copies, and
# that both that copyright notice and this permission notice appear in
# supporting documentation, ...

Actually, I wonder if pydoc profile is technically in violation of the
InfoSeek license.  More likely, however, is that the license text in
the source file is not authoritative and PSF has a more permissive
license to this code.

Skip, can you clarify where the strftime code in your patch came from?
 In your first post you said that it came from Tcl, so it may have
ActiveState copyright on at least portions of it.

On the other hand, unless strftime code is already published under an
acceptable license, I think rewriting this code from scratch would be
easier than tracking down the owners and asking them to contribute it
to python.
msg125579 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2011-01-06 19:13
Maybe rather than spending the effort maintaining a legacy API such as strftime, someone could look into implementing localized date formatting as defined by recent Unicode standards:

http://unicode.org/reports/tr35/#Date_Format_Patterns

Apparently there is a free implementation for Python out there:

http://babel.edgewall.org/wiki/Documentation/dates.html#pattern-syntax

See also msg107236 on issue #8913.
msg125584 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2011-01-06 19:56
I think we're stuck with strftime for quite a while, no matter how ugly it is. datetime.__format__ uses it, for example. Although maybe it's possible to write an strftime-format to new-format translator.

If we're going to take this on (re-writing strftime), I think the way to do it is to have it take the locale info as a parameter, and if that parameter is NULL then look up the info in the current locale. It looks like it's still a problem to find all of the info in the locale on all platforms, though. Finding the locale info is no doubt the tricky part, as someone said.

I agree it would be easier to write this from scratch rather than track down the licensing on the existing patch. As it is, there's just not much code there.
msg125585 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2011-01-06 20:22
On Thu, Jan 6, 2011 at 2:56 PM, Eric Smith <report@bugs.python.org> wrote:
..
> If we're going to take this on (re-writing strftime), I think the way to do it is to have it take the locale info as a
> parameter, and if that parameter is NULL then look up the info in the current locale.

You may want to take a look at BSD-ish strftime_l function which is
defined by POSIX.1-2008:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/strftime.html
msg125587 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2011-01-06 20:52
On Thu, Jan 6, 2011 at 11:56 AM, Eric Smith <report@bugs.python.org> wrote:
> If we're going to take this on (re-writing strftime), I think the way to do it is to have it take the locale info as a parameter, and if that parameter is NULL then look up the info in the current locale. It looks like it's still a problem to find all of the info in the locale on all platforms, though. Finding the locale info is no doubt the tricky part, as someone said.

Hm, shouldn't the libc locale support offer the same set of locales
and locale info that the libc strftime uses, on any platform? Or are
there platforms whose libc strftime has better locale support than the
libc getlocale implementation???
msg125588 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2011-01-06 21:00
The Qt library has its own strftime() implementation. The QLocale object has methods providing localized day and month names. For example, day names are implemented using a big ushort array (~20.000 bytes) which contains something like 'Sun;Mon;Tue;Wed;Thu;Fri;Sat;Sunday;Monday;Tuesday;Wednesday;Thursday;Friday;Saturday;S;M;T;W;T;F;S;7;1;2;3;4;5;6;;;;;;;;Dil;Wix;Qib;Rob;Kam;Jim;San;Dilbata;Wiixata;Qibxata;Roobii;Kamiisa;Jimaata;Sanbata;A;E;T;A;K;G;S;Aca;Etl;Tal;Arb;Kam;Gum;Sab;Acaada;Etleeni;Talaata;Arbaqa;Kamiisi;Gumqata;Sabti;1;2;3;4;5;6;7;So;Ma;Di;Wo;Do;Vr;Sa;Sondag;Maandag;Dinsdag;Woensdag;Donderdag;Vrydag;Saterdag;D;H;M;M;E;P;S;Die;H\xebn;Mar;M\xebr;(...)'.
msg125589 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2011-01-06 21:06
Is nl_langinfo() function reliable? On any OS? Can we use it to get day name, abbreviated day name, month name and abbreviated month name?

We should maybe start with an implementation in Python? It's easier to write code in Python than in C, and because it can be reused on other Python implementations.
msg146853 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-11-02 17:11
> Maybe rather than spending the effort maintaining a legacy API such as strftime, someone could
> look into implementing localized date formatting as defined by recent Unicode standards:
> http://unicode.org/reports/tr35/#Date_Format_Patterns

This scheme is very elegant.  I’d love to have built-in/stdlib support for it.  Would it need to be implemented in C?

> Apparently there is a free implementation for Python out there:
> http://babel.edgewall.org/wiki/Documentation/dates.html#pattern-syntax

Babel just rocks :)
msg163132 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2012-06-19 02:00
IANA is now distributing Olson's timezone database software which includes an implementation of strftime():

http://www.iana.org/time-zones/repository/releases/tzcode2012b.tar.gz

The code was designated as public domain by Arthur David Olson, but it seems to be based on code copyrighted by UCB and distributed under the BSD license.  The code does seem to include some locale support.
History
Date User Action Args
2014-06-29 22:36:42belopolskysetassignee: belopolsky ->
2013-09-17 05:08:48berker.peksagsetnosy: + berker.peksag
2012-10-03 01:07:52cvrebertsetnosy: + cvrebert
2012-06-19 02:00:17belopolskysetmessages: + msg163132
2012-06-14 13:29:27r.david.murraylinkissue15065 superseder
2012-04-01 06:14:55georg.brandllinkissue1396946 superseder
2011-11-03 20:20:48floxlinkissue13305 superseder
2011-11-03 20:20:48floxunlinkissue13305 dependencies
2011-11-02 17:11:24eric.araujosetnosy: + eric.araujo
messages: + msg146853
2011-11-01 00:20:25floxsetnosy: + flox
2011-10-31 21:04:59belopolskylinkissue13305 dependencies
2011-01-06 21:06:22vstinnersetnosy: gvanrossum, loewis, amaury.forgeotdarc, belopolsky, vstinner, eric.smith, schmir
messages: + msg125589
2011-01-06 21:00:34vstinnersetnosy: gvanrossum, loewis, amaury.forgeotdarc, belopolsky, vstinner, eric.smith, schmir
messages: + msg125588
2011-01-06 20:52:11gvanrossumsetnosy: gvanrossum, loewis, amaury.forgeotdarc, belopolsky, vstinner, eric.smith, schmir
messages: + msg125587
2011-01-06 20:22:07belopolskysetnosy: gvanrossum, loewis, amaury.forgeotdarc, belopolsky, vstinner, eric.smith, schmir
messages: + msg125585
2011-01-06 19:56:02eric.smithsetnosy: gvanrossum, loewis, amaury.forgeotdarc, belopolsky, vstinner, eric.smith, schmir
messages: + msg125584
2011-01-06 19:13:45belopolskysetnosy: gvanrossum, loewis, amaury.forgeotdarc, belopolsky, vstinner, eric.smith, schmir
messages: + msg125579
versions: + Python 3.3, - Python 3.0
2011-01-06 18:15:59eric.smithsetnosy: + eric.smith
2010-07-29 15:52:07belopolskysetmessages: + msg111954
2010-07-29 03:21:59gvanrossumsetkeywords: patch, patch
nosy: + gvanrossum
messages: + msg111886

2010-06-08 11:34:50amaury.forgeotdarcsetkeywords: patch, patch
nosy: + amaury.forgeotdarc
messages: + msg107315

2010-06-06 00:29:19belopolskysetnosy: + belopolsky
messages: + msg107168

assignee: belopolsky
keywords: patch, patch
type: enhancement
2010-05-20 20:34:16skip.montanarosetkeywords: patch, patch
nosy: - skip.montanaro
2008-11-11 04:11:23vstinnersetkeywords: patch, patch
nosy: + vstinner
messages: + msg75730
2008-08-05 22:32:26schmirsetnosy: + schmir
2008-07-02 13:42:36skip.montanarosetkeywords: patch, patch
messages: + msg69092
2008-06-23 03:54:36loewissetkeywords: patch, patch
nosy: + loewis
messages: + msg68606
2008-06-23 02:47:09skip.montanarosetkeywords: patch, patch
messages: + msg68604
2008-06-23 02:44:52skip.montanarocreate