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 tungwaiyip
Recipients
Date 2004-11-29.05:30:10
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
Logged In: YES 
user_id=561546

I don't understand the issue with strftime() and strptime(). If 
datetime supports microsecond and time doesn't, the user just 
have to trim the microsecond off like:
  strptime( str(datetime.now())[:-7], format)

The problem is the above won't work. And that's why I filed 
this bug. It fails if datetime.now() just happen to have 
microsecond value of 0.

How often this happen is not the issue. The issue is it should 
be deterministic. Actually an issue that happens 1/1000th of 
time is a lot more problematic than an issue that happens 
consistently.

A preferable design is to have datetime to take an extra flag 
to indicate if microsecond is wanted. Or a datetime class that  
supports second precision and a subclass that supports 
microsecond. The user should make a choice on how much 
precision should be used, not leaving it up to chance.
History
Date User Action Args
2007-08-23 16:08:34adminlinkissue1074462 messages
2007-08-23 16:08:34admincreate