0

I am saving the last time a page has been visited, and since I upgraded to Django 1.8, all my dates went wonky... And I really, really dont get it.

I basically have an API that is being poked by kiosk computers set all around the US, but I want to know if at a point in time the kiosk has checked in in the last 3 minutes or not. I don't care in which timezone it is.

I have a simple datetimefield: 

lastcheckintime = models.DateTimeField(blank=True, null=True, auto_now=False)

And when the API is called, I simply save this: 

monitor.lastcheckintime = timezone.now()

With a debug log, looks like it's saving the right UTC time in the database. I'm checkin if a monitor is online with this: 

@property
def is_online(self):
    if self.lastcheckintime is None:
        return False

    time_threshold = timezone.now() - timedelta(minutes=3)
    return self.lastcheckintime > time_threshold

It used to be perfect until I upgraded. I can't tell if it's the upgrade of Django to 1.8 or pytz itself, but now it looks like this:

Last 3 lines are wonky

(In my timezone it's 10:29pm)

And the weird part is that these lines change ! It's not always the same monitor that's on the wrong time. Also, the whole thing is off by 7 hours (I'm GMT -7). Any other model looks to work correctly, I'm completely lost on why this one is behaving erratically.

Any idea on something I might have missed?

Thanks!

Alb Dum
  • 1,121
  • 3
  • 11
  • 26
  • 2
    I can't think of anything that changed in 1.8 that would cause this. What is the value of `USE_TZ`? The behavior you're seeing kind of looks like you went from using `USE_TZ=True` to `USE_TZ=False`. – Kevin Christopher Henry Jul 10 '15 at 06:50
  • The [`timezone.now()` source code](https://github.com/django/django/blob/2e05ef4e18c8fea0c199e4fc32278cce11158ac0/django/utils/timezone.py#L316) also hints that `settings.USE_TZ` might have changed in your environment. – jfs Jul 10 '15 at 10:12
  • My USE_TZ is still set to true. In my case it shouldn't matter in which timezone each device is set to, right? (They should all be in the same one anyways) – Alb Dum Jul 10 '15 at 23:04
  • @AlbanDumouilla: it is your responsibility, to make sure that all parts of the system (db, OS, django) use the same timezone e.g., to avoid that utc time is interpreted as a local time and in reverse. – jfs Jul 11 '15 at 18:54
  • @J.F.Sebastian yes, they all are. See my answer below, I just recreated the exact same field with a different name and everything works fine. Not sure what happened there, as I don't believe that the field itself could get on a different timezone. – Alb Dum Jul 12 '15 at 19:01
  • I am actually wondering if in the end it might be the same issue than this guy has: http://stackoverflow.com/questions/31303120/is-django-corrupting-timezone-aware-datetimefield-when-saving-it-to-the-database – Alb Dum Jul 12 '15 at 19:10

1 Answers1

0

Still can't understand what happened, but I ended up creating another datetimefield with the exact properties and use this one instead, delete the old lastcheckintime and everything works just fine.

This is still a mystery though... Thanks!

Alb Dum
  • 1,121
  • 3
  • 11
  • 26