Re: django.forms.DateTimeField and timezones

[Aymeric Augustin]

2012/11/27 Ion Scerbatiuc <delin...@gmail.com>

The datetimes in the POST are created using timezone.now() (and I have USE_TZ = True)

The POST data simulates the values entered by the user in the form. It should contain naive datetimes in local time.

Actually, to be realistic, it should contain strings representing naive date times, because that's what will be POST-ed by a HTML form. But using a datetime object works too.

I'm wondering if someone encountered this issue before, or if there is already a ticket submitted. I personally failed to find one, but maybe I just suck at searching Trac.

As far as I know, you're the first one to report this problem.

We have two options:

  - improve the code so an aware datetime is accepted as form input, and passed-through unchanged;

  - document this as a known pitfall.

Could you file a ticket in Trac? I'll take a look as soon as possible.

--
Aymeric.

[Ion Scerbatiuc]

Hey,

Thanks for the quick response. You can see my comments in-line.

On Tuesday, November 27, 2012 3:12:39 PM UTC+2, Aymeric Augustin wrote:

2012/11/27 Ion Scerbatiuc <delin...@gmail.com>

The datetimes in the POST are created using timezone.now() (and I have USE_TZ = True)

The POST data simulates the values entered by the user in the form. It should contain naive datetimes in local time.

 

I'm sorry I was a little bit unclear. The datetimes are created using timezone.now() but the request factory receives a string representing the datetime using .isoformat(' '). 

Actually, to be realistic, it should contain strings representing naive date times, because that's what will be POST-ed by a HTML form. But using a datetime object works too.

I'm not 100% sure that the datetimes received in the POST should represent naive date times. I mean there might be use cases when they represent aware datetimes:

• there is a custom widget that allows the user to specify the timezone
• the data is coming through a REST API and you have a form handling the validation
• ...

I'm wondering if someone encountered this issue before, or if there is already a ticket submitted. I personally failed to find one, but maybe I just suck at searching Trac.

As far as I know, you're the first one to report this problem.

We have two options:

  - improve the code so an aware datetime is accepted as form input, and passed-through unchanged;

  - document this as a known pitfall.

Could you file a ticket in Trac? I'll take a look as soon as possible.

I will definitely create a ticket in Trac and provide more information on my use case. I'll post the ticket number on this thread for visibility when I'm done.

 

--
Aymeric.

Ion

 

[Aymeric Augustin]

2012/11/27 Ion Scerbatiuc <delin...@gmail.com>

Actually, to be realistic, it should contain strings representing naive date times, because that's what will be POST-ed by a HTML form. But using a datetime object works too.

I'm not 100% sure that the datetimes received in the POST should represent naive date times. I mean there might be use cases when they represent aware datetimes:

• there is a custom widget that allows the user to specify the timezone
• the data is coming through a REST API and you have a form handling the validation
• ...

Indeed, if the string contains timezone information (ie. Z or +03:00), Django should take it into account.

--
Aymeric.

[Ion Scerbatiuc]

For whom might be interested: just created the ticket and attached a regression test case for details: https://code.djangoproject.com/ticket/19371

Ion