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

[Mark Essien <markessien@…>]

To recreate:

1. Setup Django on a Windows XP system with the Time Format set to German (19/8/2008)

2. Save the data using manage.py dumpdata > initial_data.json<br>

3. Reload the data using manage.py 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\loaddata.py", 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.name] = field.to_python(field_value)
  File "C:\Program Files\Python\Lib\site-packages\django\db\models\fields\__init
__.py", 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.']

[Bob Thomas]

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.

[Anders Er]

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/loaddata.py", line 150, in handle
    for obj in objects:
  File "/usr/lib/python2.5/site-packages/django/core/serializers/xml_serializer.py", line 131, in next
    return self._handle_object(node)
  File "/usr/lib/python2.5/site-packages/django/core/serializers/xml_serializer.py", line 176, in _handle_object
    value = field.to_python(getInnerText(field_node).strip())
  File "/usr/lib/python2.5/site-packages/django/db/models/fields/__init__.py", 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.

[Alex Gaynor]

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.

[Karen Tracey]

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.

[Anders Er]

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

I.e.:

{"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):
    empty_strings_allowed=False
    def get_internal_type(self):
        return "BigIntegerField"

    def db_type(self):
        if settings.DATABASE_ENGINE == 'oracle':
            return 'NUMBER(19)'
        else:
            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

[Anders Er]

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