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.

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.

So how does it work for non-English locales?

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

The issue #1777412 has a working patch (for Python 2.6) which allows 
year < 1900 in time.strftime() and datetime.datetime.strftime().

What platforms have broken strftime and how badly is it broken there?

Is there a python version somewhere?  PyPy?

PyPy also calls the platform's strftime().

What about the licensing? That look like the BSD license *with* advertising clause...

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.

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.

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.

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

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???

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;(...)'.

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.

> 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 :)

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.