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 belopolsky
Recipients amaury.forgeotdarc, belopolsky, brett.cannon, brian.curtin, daniel.urban, davidfraser, eric.araujo, giampaolo.rodola, lemburg, mark.dickinson, pitrou, r.david.murray, rhettinger, techtonik, tim.peters, vstinner
Date 2010-10-05.17:52:22
SpamBayes Score 8.74356e-13
Marked as misclassified No
Message-id <>
In-reply-to <>
On Thu, Aug 12, 2010 at 10:26 PM, STINNER Victor <> wrote:
>> 1. time source (time.time()) represents time as
>> a floating point number which leads to system dependent behavior
>> and introduces floating point operations where they are not needed.
> Why not introducing a new function in time module? Other people may benefit from this.
I agree.  See issue 9079.

We can do that.  I'll experiment with this approach within issue 9527.

>> 4. No changes will be done to timemodule.c other than renaming
> What about time_strftime()? It is 170 lines long: will it be moved to _basictime.c? You have to keep
> the code filling the "struct tm" structure in (_)timemodule.c.

No, I don't want  time_strftime in _basictime.  I want
datetime_strftime to be independently implemented and freed of legacy
restrictions on the year range.   The _basictime module should include
a very simple wrapper around system strftime if we want to keep using
it in, but it would be best to have complete pure python
implementation of both strftime and strptime.
Date User Action Args
2010-10-05 17:52:27belopolskysetrecipients: + belopolsky, lemburg, tim.peters, brett.cannon, rhettinger, amaury.forgeotdarc, mark.dickinson, davidfraser, pitrou, vstinner, techtonik, giampaolo.rodola, eric.araujo, r.david.murray, brian.curtin, daniel.urban
2010-10-05 17:52:23belopolskylinkissue9528 messages
2010-10-05 17:52:22belopolskycreate