Pull requests

#83 Open
ryanbagwell ryanbagwell
david david

converting s3 last modified time to local time so it can be properly compared by django to the local file modification time.

Bitbucket cannot automatically merge this request due to conflicts.

Review the conflicts on the Overview tab. You can then either decline the request or merge it manually on your local system using the following commands:

hg update default
hg pull -r default https://bitbucket.org/ryanbagwell/django-storages
hg merge e81c2e9540e2
hg commit -m 'Merged in ryanbagwell/django-storages (pull request #83)'
  1. ryanbagwell

This PR converts the s3 last modified file time to the local machine's time for comparison purposes. Otherwise, Django won't always delete the file if its older.

issue #167

Comments (6)

  1. Ian Lewis

    I think this is actually not the best solution as there are a number of timezones that are in play. i.e. The system timezone, the TIME_ZONE setting, the timezone as returned from S3.

    This PR uses the TIME_ZONE setting which can be different from the system timezone which is what the FileSystemStorage uses. The django docs explicitly state that it the system timezone and TIME_ZONE setting could be different (they do need to be the same on Windows though).

    I sent a message to the django-users mailing list to see if there is any consensus on which timezone to use. I have a feeling that the FileSystemStorage is going to be a de facto standard and that the system timezone is actually what we should be using.


    1. Ian Lewis

      I'm not sure actually. Could you test and see what happens to the modified time in FileSystemStorage when the system timezone is not set?

  2. jaylett

    Having tested this more thoroughly, my previous comment is wrong; os.environ['TZ'] gets used (but that is usually set from settings.TIME_ZONE).