Opened 8 years ago

Closed 7 years ago

#8412 closed (worksforme)

When there is a DateTimeField in, data saved with dumpdata cannot be reloaded using loaddata (on German Systems)

Reported by: Mark Essien <markessien@…> Owned by: nobody
Component: Core (Serialization) Version: 1.1-beta
Severity: Keywords: loaddata dumpdata DateTimeField
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


To recreate:

  1. Setup Django on a Windows XP system with the Time Format set to German (19/8/2008)
  1. Save the data using dumpdata > initial_data.json<br>
  1. Reload the data using loaddata initial_data.json<br>

The message appears:

Problem installing fixture 'initial_data.json': Traceback (most recent call last
  File "C:\Program Files\Python\Lib\site-packages\django\core\management\command
s\", line 108, in handle
    for obj in objects:
  File "C:\Program Files\Python\Lib\site-packages\django\core\serializers\json.p
y", line 42, in Deserializer
    for obj in PythonDeserializer(simplejson.load(stream)):
  File "C:\Program Files\Python\Lib\site-packages\django\core\serializers\python
.py", line 93, in Deserializer
    data[] = field.to_python(field_value)
  File "C:\Program Files\Python\Lib\site-packages\django\db\models\fields\__init", line 631, in to_python
    raise validators.ValidationError, _('Enter a valid date/time in YYYY-MM-DD H
H:MM format.')
ValidationError: [u'Enter a valid date/time in YYYY-MM-DD HH:MM format.']

Change History (8)

comment:1 Changed 8 years ago by jacob

  • milestone set to 1.1
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

comment:2 Changed 7 years ago by bthomas

I cannot reproduce this. DateTimeFields are always serialized to the format "%Y-%m-%d %H:%M:%S", and DateTimeField.to_python always accepts the same. The time format in Windows does not appear to affect this at all (though I'm still using English-language Windows, just with the time format changed). The exact error message in this bug no longer appears to exist, so it's clear some changes have been made here.

comment:3 Changed 7 years ago by jacob

  • Resolution set to worksforme
  • Status changed from new to closed

comment:4 Changed 7 years ago by anderser

  • Resolution worksforme deleted
  • Status changed from closed to reopened
  • Version changed from SVN to 1.1-beta-1

I have the same issue on Ubuntu with Django 1.1 beta 1 after creating a fixture with the option --format xml. Same applies if format json is used.

Output from loaddata command:

Problem installing fixture '/tmp/mydata.xml': Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/django/core/management/commands/", line 150, in handle
    for obj in objects:
  File "/usr/lib/python2.5/site-packages/django/core/serializers/", line 131, in next
    return self._handle_object(node)
  File "/usr/lib/python2.5/site-packages/django/core/serializers/", line 176, in _handle_object
    value = field.to_python(getInnerText(field_node).strip())
  File "/usr/lib/python2.5/site-packages/django/db/models/fields/", line 565, in to_python
    _('Enter a valid date/time in YYYY-MM-DD HH:MM[:ss[.uuuuuu]] format.'))
ValidationError: Enter a valid date/time in YYYY-MM-DD HH:MM[:ss[.uuuuuu]] format.

comment:5 Changed 7 years ago by Alex

  • milestone 1.1 deleted

a) Can you please provide a reproducable test case for this? So far we've just seen a string of exceptions with no context.
b) This is not a 1.1 blocker.

comment:6 Changed 7 years ago by kmtracey

Information on how the dates are actually formatted in the generated fixture files would also be interesting.

Also please confirm the version you are running. From a brief check it does not appear to me that the most recent traceback posted matches up to 1.1 beta code.

comment:7 Changed 7 years ago by anderser

Date format in dumpfile (JSON) is " 9-04-18 06:41:57" - seems the 200 in 2009 has vanished.


{"pk": 2893, "model": "tweet.twittermessage", "fields": {"t_id": 786425719, "text": "My cool message here", "created_at": "   8-04-10 02:46:33", "user": 14349782}},

Model/custom field:

class BigIntegerField(IntegerField):
    def get_internal_type(self):
        return "BigIntegerField"

    def db_type(self):
        if settings.DATABASE_ENGINE == 'oracle':
            return 'NUMBER(19)'
            return 'bigint'

class Twitteruser(models.Model):
    username = models.CharField(max_length=20)
    verified = models.BooleanField(default=False, editable=False)

class Twittermessage(models.Model):
    t_id = BigIntegerField(null=False, blank=False, unique=True)
    user = models.ForeignKey(Twitteruser)
    created_at = models.DateTimeField()
    text = models.CharField(max_length=180)

I suspect this to have something with my custom BigIntegerField.

The dumpdata is done from a MySql DB using Django 1.1 RC 1. The loaddata is done into a Oracle DB using Django 1.1 Beta 1

comment:8 Changed 7 years ago by anderser

  • Resolution set to worksforme
  • Status changed from reopened to closed

My bad. Dates in the originale table were by some reason stored as 0009-04-05 etc. This of course caused trouble.

Note: See TracTickets for help on using tickets.
Back to Top