dateTime.now() return format missing decimal seconds.

[Dave]

BPO	17139
Nosy	@mdickinson, @vstinner, @bitdancer

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2013-02-06.18:55:57.760>
created_at = <Date 2013-02-05.21:43:47.550>
labels = ['type-bug', 'invalid', 'OS-windows']
title = 'dateTime.now() return format missing decimal seconds.'
updated_at = <Date 2013-02-07.01:06:12.179>
user = 'https://bugs.python.org/Dave'

bugs.python.org fields:

activity = <Date 2013-02-07.01:06:12.179>
actor = 'Dave'
assignee = 'none'
closed = True
closed_date = <Date 2013-02-06.18:55:57.760>
closer = 'r.david.murray'
components = ['Windows']
creation = <Date 2013-02-05.21:43:47.550>
creator = 'Dave'
dependencies = []
files = []
hgrepos = []
issue_num = 17139
keywords = []
message_count = 14.0
messages = ['181484', '181485', '181486', '181487', '181490', '181491', '181492', '181493', '181494', '181534', '181558', '181566', '181567', '181577']
nosy_count = 4.0
nosy_names = ['mark.dickinson', 'vstinner', 'r.david.murray', 'Dave']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue17139'
versions = ['Python 2.7', 'Python 3.2', 'Python 3.3', 'Python 3.4']

[Dave]

Calling datetime.datetime.now() will return only the Date and time to the second w/o the decimal portion when the second increments when also running firefox w/shockwave flash enabled on a windows 7 machine.

Example output:
counter1 is: 23360 time is: 2013-02-05 16:32:24.999000
counter1 is: 23361 time is: 2013-02-05 16:32:25
counter1 is: 23362 time is: 2013-02-05 16:32:25.002000
Notice the missing decimal value on the middle one.

To reproduce:
Code:
counter = 0
while(True):
counter +=1
time = datetime.datetime.now()
numericDateTime =
print("counter1 is: " + str(counter) + " time is: " + time)

I can get this to occur every time that firefox is running with Shockwave flash enabled.
datetime.now() works fine w/o firefox running w/shockwave flash enabled.

I believe the datetime.now() should always return the same format.

[vstinner]

I believe the datetime.now() should always return the same format.

It's now how it was implemented:
http://docs.python.org/dev/library/datetime.html#datetime.datetime.\_\_str__
and
http://docs.python.org/dev/library/datetime.html#datetime.datetime.isoformat

[mdickinson]

See also issue bpo-1074462

[mdickinson]

This is a feature request rather than a bug report; changing fields accordingly.

Also, given the discussion leading to the rejection of bpo-1074462, and the fact that you can now use %f in strftime as an easy way to get consistent output (bpo-1158), I'm closing this as rejected.

>>> d = datetime.datetime(2013, 10, 11, 12, 34, 56, 0)
>>> d.strftime("%Y-%m-%d %H:%M:%S.%f")
'2013-10-11 12:34:56.000000'

[Dave]

I appreciate you guys looking into this so quickly, but let's dig a little deeper.

1. STINNER Victor, you claim this is already fixed in 3.4 by the link, however this doesn't really help since I'm not even up to 3.3 yet (though I'm considering it, I meant to select 3.2 above). No one has yet provided any insight into why this condition only occurs when firefox is up running shockwave flash...(to me this is an even bigger question as I have a 7 other rather under tasked cores at my disposal).

2. Mark Dickinson, let's break this down. I've already worked around it as I’m sure that EVERYONE ELSE WHO USES IT has already done as well... We know as coders it's more difficult to work with a varying format (no advantage there). Which begs the question why not fix it so everyone doesn't have to? By the issue you referenced it's been known and unfixed since at least since 2004. Also, no curiosity why this only occurs when running firefox w/shockwave flash?

Again I do appreciate you guys looking into this so quickly, but I don't know if this is actually going to get fixed, why it wasn't fixed in 2004, or is the Python motto "it's not broke if there exists a workaround". Odd that more time was spent talking about this (and Mark and myself independently implemented actual fixes) than the fix would have taken to apply to the baseline(I used to see this much other places I've worked). But I'm happy to say, I never saw responses back so quickly, which is very hopeful.

Sincerely,
Dave

[Dave]

Point was/is that I'd be willing to fix this so that others don't have to. It's for OTHERS SAKE that I submitted this issue as my system is already bullet proof from this defect/lack of feature situation. This is also my first attempt to get involved with the freeware community.

Thanks,
Dave

[bitdancer]

I think Victor meant "not" instead of "now".

It doesn't only occur when your run particular programs, it occurs whenever the microseconds are zero. It is possible that your particular combination of programs produces a timing pattern that means you see microseconds zero more often in your tests.

Keep in mind that the str is a *convenience* representation. As such it is *much* more convenient to not print the zero microseconds in the very common case of constructed datetimes that have zero microseconds.

If you want to strictly control the representation you want to use specific formatting, which you can do.

Thus the rejection.

[Dave]

Thanks David Murry for clearing up STINNER Victor comments. I already feel like I work here;) So "it's not broke if there exists a workaround".

In that case it's time to update the documents (which often takes longer than the code to update) to reflect this inconsistency so others won't run into this like I did (it took time to trouble shoot this as it was occurring prior to my logging being set up). It then took time to trap until I started web browsing:)

State clearly in the API that the output format is either:
"2013-02-05 16:32:24.999000" or
"2013-02-05 16:32:25"
depending on the time returned.

I would also suggest deprecating the now(), __str__ and any method that exhibits this inconsistent multi-format output behavior since everyone after reading the updated comments will switch to another method immediately for simpler/more robust code.

David Murry, said "Keep in mind that the str is a *convenience* representation. As such it is *much* more convenient to not print the zero microseconds in the very common case of constructed datetimes that have zero microseconds." Interesting since currently datetime does print the zeros microseconds in my example: "2013-02-05 16:32:24.999000" (notice the last 3 zeros are microseconds returned/printed by datetime.now()). Apparently this is inconvenient by your standards was well.

I'm moving the status back to open for the documentation update and we'll see how anyone feels about the deprecation.

All these little efforts have added up to something great "Python" and I hope these discussion will help further that cause. I appreciate everyone who has participated.

Thanks,
Dave