Microsecond discrepancy between Django and Python

Question

I use a datetime property as part of a dynamic form's controls naming convention. I noticed that Python microseconds in a DateTime property are always 6 characters in length even if the first character is a 0. On my Django form though, the Django microseconds drops the leading 0.

Here is my Django:

name="foo-{{datecreated|date:'Y-m-d H:i:s.u}}"

Which creates:

name="foo-2013-11-15 15:41:33.40350"

Here is my Python (in a data model in appengine):

datecreated = db.DateTimeProperty(auto_now_add = True)

Which results in:

datecreated: 2013-11-15 15:41:33.040350

I do not see this mentioned in the Django or Python documentation. Any ideas?

UPDATE: Based on the very helpful suggestions below I have confirmed the problem is in fact that the current supported version of Django in App Engine has a bug. Regarding a workaround until Django 1.6 is supported, this is what I was thinking of doing. Basically checking the length of the microsecond string in Django and concatenating a leading 0 if necessary. Is there some disadvantage Im missing?

{%if datecreated|date:'u'|length == 6 %}render control name as above 
{% else %} 
<input type="radio" name="foo-{{datecreated|date:'Y-m-d H:i:s'}}{{datecreated|date:'.0u'}}"

Answer 1

Looking at your code, and the link to the php reference, I think this is happening:

• Django notes that "These format characters are not used in Django outside of templates. They were designed to be compatible with PHP to ease transitioning for designers" ( as @Leonardo.Z mentioned ) ]

• looking at the Django Docs for the date templating format [https://docs.djangoproject.com/en/dev/ref/templates/builtins/#date] , most items specifically mention whether or not there are leading zeroes

• microseconds merely states 000000 to 999999

• looking at the php docs [http://bd1.php.net/manual/en/function.date.php] , most things explicitly state with/without leading zeroes

• php states : Microseconds (added in PHP 5.2.2). Note that date() will always generate 000000 since it takes an integer parameter, whereas DateTime::format() does support microseconds. Example: 654321 Microseconds (added in PHP 5.2.2). Note that date() will always generate 000000 since it takes an integer parameter, whereas DateTime::format() does support microseconds. Example: 654321

So this basically looks to me like someone isn't zero-padding the template strings, although they should, because the original docs the function was written to be in compliance with were bad.

Let's look at the source for microseconds :

Django date parsing looks to be right : https://github.com/django/django/blob/master/django/utils/dateparse.py

I imagine this is the date writing tag : https://github.com/django/django/blob/c347f78cc1b2a06958f692f0622deceac534dc6b/django/utils/dateformat.py#L173-L175

and look, it's zero-padding the date in there.

So let's look at the history of the file...

zeropadding was introduced in this commit: https://github.com/django/django/commit/822cfce3df53301d9f9f4c14bd8a0cb2a1956e2e

That commit is over a year old, and part of 1.6c1 , the release candidate, which predates the current actual django production release.

tldr; you have an old version of django with a known bug. update django.

Answer 2

Django doc mentioned it.

date

Formats a date according to the given format.

Uses a similar format as PHP's date() function ( http://php.net/date ) with some differences.

These format characters are not used in Django outside of templates. They were designed to be compatible with PHP to ease transitioning for designers.

Besides that, I think you might confused date/datetime objects with their string representings.

What you said Here is my Django: actually is in Django templates . Outside of templates, in views and models, date/datetime objects are same with those in non-django projects.

What you said Here is my Python , actually is in Google Appengine ndb DateTimeProperty .

Python's official datetime string representing format( strftime ) does not include microsecond., I think that's one of the reason why django choose to use PHP's.