Django

Code

Ticket #9459 (new)

Opened 2 years ago

Last modified 4 months ago

forms.DateTimeField() rendered with HiddenInput looses microseconds

Reported by: guettli Assigned to: nobody
Milestone: Component: Forms
Version: 1.0 Keywords:
Cc: hv@tbz-pariv.de Triage Stage: Accepted
Has patch: 1 Needs documentation: 0
Needs tests: 0 Patch needs improvement: 1

Description

forms.DateTimeField?() looses the microseconds if you render it with HiddenInput?.

A patch and unittest are attached.

Attachments

datetimefield-microseconds.diff (1.6 kB) - added by guettli on 10/28/08 09:03:46.

Change History

10/28/08 09:03:46 changed by guettli

  • attachment datetimefield-microseconds.diff added.

02/26/09 13:51:13 changed by jacob

  • needs_better_patch changed.
  • needs_docs changed.
  • stage changed from Unreviewed to Accepted.
  • needs_tests changed.
  • milestone set to 1.1.

02/26/09 15:14:50 changed by tobias

if you just want this to work and you don't want to patch django you can use this:

http://www.djangosnippets.org/snippets/1342/

04/07/09 22:02:47 changed by stryderjzw

On a related note:

Rendering the DateTimeField? as a hidden field, {{ field.as_hidden }}, will make the form invalid when submitting because the HiddenInput? keeps the microseconds and the field validation does not.

05/02/09 09:50:25 changed by russellm

  • needs_better_patch set to 1.
  • milestone deleted.

The proposed patch is extremely brittle - it only works providing you don't use a '.' in the your custom rendering of datetime. If you allow an input format of '%Y.%m.%d %H:%M:%S", the code will break hard.

If you dig into the code, it isn't just HiddenField? that is affected by this - the default DateTimeField? also loses milliseconds. Essentially, what is required is a way to parse milliseconds from a string. Python 2.6 adds %f to strftime/strptime, which will solve this problem - you can then allow "%Y-%m-%d %H:%M:%S.%f" as an input format. We may need to port strftime and strptime back from Python 2.6. Other options also welcome.

This problem:

  1. Is Annoying
  2. Has always existed in newforms, and probably in oldforms before that
  3. Only affects a subset of the user community

Since the required fix will be quite big, and we're already overdue for v1.1, I'm going to drop this from the v1.1 roadmap. If someone wants to tackle porting strptime and strftime (and this includes resolving any licensing issues) and they can get a patch ready quickly, feel free to put this back on the v1.1 path.

05/26/09 09:25:34 changed by tobias

Slightly more acceptable approach, with a couple bug fixes:

class DateTimeWithUsecsField(forms.DateTimeField):
    def clean(self, value):
        if value and '.' in value: 
            value, usecs = value.rsplit('.', 1)
            usecs += '0'*(6-len(usecs)) # right pad with zeros if necessary
            try:
                usecs = int(usecs) 
            except ValueError: 
                raise ValidationError('Microseconds must be an integer') 
        else: 
            usecs = 0 
        cleaned_value = super(DateTimeWithUsecsField, self).clean(value)
        if cleaned_value:
            cleaned_value = cleaned_value.replace(microsecond=usecs)
        return cleaned_value

Also updated at http://www.djangosnippets.org/snippets/1342/

(follow-up: ↓ 7 ) 03/23/10 09:31:50 changed by bjunix

The version of this ticket is 1.0. I guess this bug also affects trunk. Can someone confirm this and change the Version to SVN?

(in reply to: ↑ 6 ; follow-up: ↓ 8 ) 03/23/10 09:48:04 changed by kmtracey

Replying to bjunix:

The version of this ticket is 1.0. I guess this bug also affects trunk. Can someone confirm this and change the Version to SVN?

If the version when reported was 1.0, and the ticket is still open, then likely the behavior is still present in trunk. (There's some chance an unrelated or unrealized-duplicate ticket changed the behavior, so it's only likely and not certain, but it seems unlikely that has happened in this particular case.)

Changing the version to SVN is unnecessary and actually unhelpful, for a couple of reasons. First, you lose the easy access to the information that the behavior has existed as far back as 1.0. Also, version being set to SVN is a possible indication of a regression: behavior that did not exist in previous released versions but exists now in trunk. Those tickets are particularly important to resolve before a release, so setting version to SVN for behavior that has existed since forever is counter-productive for the release team.

(in reply to: ↑ 7 ) 03/23/10 14:19:49 changed by bjunix

Replying to kmtracey: My bad. Thanks for the detailed explanation.


Add/Change #9459 (forms.DateTimeField() rendered with HiddenInput looses microseconds)




Change Properties
Action