[ python-Feature Requests-1074462 ] Irregular behavior of datetime.__str__()

[SourceForge.net]

Feature Requests item #1074462, was opened at 2004-11-27 21:18
Message generated for change (Comment added) made by tungwaiyip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1074462&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Wai Yip Tung (tungwaiyip)
Assigned to: Nobody/Anonymous (nobody)
Summary: Irregular behavior of datetime.__str__()

Initial Comment:
>From documentation of datetime.isoformat() and 
__str__() :

Return a string representing the date and time in ISO 
8601 format, YYYY-MM-DDTHH:MM:SS.mmmmmm or, if 
microsecond is 0, YYYY-MM-DDTHH:MM:SS


This behavior assume if microsecond is 0, it means the 
user don't need microsecond precision. This is a poor 
assumption because obviously the user may want 
microsecond precision but its value just happen to be 0. 
Now the output is irregular the user can't even use string 
slicing without checking the length of the output first.

Similar behavior found in 

timedelta.__str__()

time.isoformat()



----------------------------------------------------------------------

>Comment By: Wai Yip Tung (tungwaiyip)
Date: 2004-12-02 11:17

Message:
Logged In: YES 
user_id=561546

You didn't get the problem case. The microsecond is wanted 
but it happens to be 0. Now I can't get a timestamp aligned 
without some doing some extra checking.

I also hate complicating signatures. So my recommendation 
really is to remove the one line of if statement and have it 
always output the microsecond as a fixed size string. Python 
will have one less test case. The user will get a fix sized string 
they can easily slice to get any precision they want.

The current logic really only complicate things. If you take it 
one step further and skip minute and second if they are all 0, 
it will probably be more of an annoyonce than useful. Nor is 
the trimming trailing zeros rationale is actually taking place 
here. On Windows str(now()) always have the last 3 digits 0, 
except in the 1/1000 of time when the microsecond happens 
to be 0.

Nothing is fatal flawed here. Right now I just avoid str() and 
use the strptime() instead. The problem is just the extra logic 
in str() actually make it less useful.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-12-01 18:50

Message:
Logged In: YES 
user_id=31435

Sorry, I really don't see a point to this.  The claim that slicing 
doesn't work is unbelievable on two counts:

1. If someone has a datetime object D, and wants, e.g.,
   the year, they don't do str(D), try to slice out the year
   digits, then convert them to an int(!) -- they just do
   D.year.  Same for the other members (including
   D.microsecond).

2. Slicing works anyway.  For example, str(D)[:4] gets
   the year digits regardless of D.microsecond.  str(D)[17:]
   gets the seconds likewise, and float(str(D)[17:]) gets
   the number of seconds as a float regardless of whether
   D.microsecond is 0.

If you want D without microseconds, the intended way to do 
it is one of:

a) Don't set microseconds if you don't want microseconds;

or, if you're stuck with unwanted microseconds,

b) Use D.replace(microsecond=0) to get a copy of D
   but with microsecond forced to 0.

The current behavior is by design, and documented, so won't 
be changed regardless.

I'm somewhere between -1 and -0 on complicating signatures 
to give a shortcut for something that's rarely needed and 
easy to get anyway.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-12-01 14:07

Message:
Logged In: YES 
user_id=357491

OK, look at it in terms of math; trailing zeros are almost always 
truncated from numbers because they are superfluous.  The same is 
happening here; the superfluous zeros after the decimal are just being 
truncated.

And you can also just as easily detect if there are no trailing zeros and 
tack them on if you prefer::

iso = datetime.datetime.now().isoformat()
if '.' not in iso: iso = '%s.000000' % iso

Because the docs clearly state this behavior I am changing this to a 
feature request for Python 2.5 .

But I do understand the desire to make parsing easier.  If Tim Peters is 
okays the API change I will patch it to take an optional argument which 
will force a microsecond output.  But personally I am -0 on the option.

You listening by any chance, Tim?

----------------------------------------------------------------------

Comment By: Wai Yip Tung (tungwaiyip)
Date: 2004-11-28 21:30

Message:
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.


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-11-28 11:58

Message:
Logged In: YES 
user_id=357491

But there is a reason for this behavior; strftime() and strptime() do not 
support microsecond values.  If you are working with those two functions 
those values will cause you issues when specifying the directives.  And 
the chances of actually having a 0 microsecond if you are using them is 
rather small to say the least.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1074462&group_id=5470