Synnefo

Διευκρίνιση μετά από σημερινή συνάντηση:
αυτό πρέπει να διερευνηθεί. Αν είναι bug του Firefox, πρέπει να βρεθεί συγκεκριμένη αναφορά, ή να του ανοιχτεί bug.
Αν δεν είναι, και είναι bug της τοπικής Javascript, πρέπει να διορθωθεί.

Πλέον εκτός από clearTimeout κάνουμε και abort τα pending ajax requests όταν αλλάζει το standard/list view, το οποίο φαίνεται να λύνει το πρόβλημα σε όλες τις περιπτώσεις.

Παίζει σίγουρα καλύτερα από πριν, πλέον δεν κολλάει αν πηγαίνω από list view σε standard view και πάλι πίσω. Κολλάει αν κάνω τετραπλό πενταπλό γρήγορο κλικ πάνω στο κάγκελο του list view. Βγαίνει ο spinner για πάντα και δεν αντικαθίσταται ποτέ. Αν πάω μετά αργά-αργά list-view και πάλι πίσω standard view, ή αν το αφήσω ώρα και μετά ξαναπατήσω το κάγκελο, όλα ΟΚ.

Αλλά το κολλάω όποτε θέλω αν κάνω 3πλο γρήγορο κλικ πάνω στο κάγκελο. Οπότε υπάρχει θέμα ακόμη.

Διορθώθηκε και αυτό

Πράγματι δεν κολλάει πλέον, αλλά σταμάτησε να κάνει refresh η σελίδα εντελώς.
Δεν ανανεώνεται ποτέ δυναμικά το περιεχόμενο της σελίδας, όταν ο χρήστης ζητήσει να γίνει κάτι σε VM.

Οπότε αυτό δεν μπορεί να κλείσει.

Αν αλλάξεις το ΤΙΜΕ_ΖΟΝΕ σε "UTC" στο settings.py δεν θα πρέπει να έχεις πλέον πρόβλημα.

Μπορείς να εξηγήσεις λίγο παραπάνω γιατί χρειάζεται το TIME_ZONE να γίνει UTC;
Αφού η Ελλάδα είναι UTC+2, το σύστημα πρέπει να λειτουργεί με TIME_ZONE=UTC+2.

Τι επηρεάζεται από αυτό;
Αν γίνεται συμπλήρωσε το παρόν ticket και [μετά, αν υπάρξει συμφωνία] βάλε ανάλογη τεκμηρίωση στον κώδικα, στο σημείο που επηρεάζεται από την τιμή της ρύθμισης TIME_ZONE.

Με την παραπάνω ρύθμιση το Django αποθηκεύει όλες τις ημερομηνίες εσωτερικά σε UTC. Επηρεάζονται όλα τα DateTimeField.

To UTC είναι καλύτερη επιλογή νομίζω μιας και δεν αλλάζει για daylight savings. Η Ελλάδα είναι αλλάζει από UTC+2 σε UTC+3. Αν σε κάποιο σημείο το πρόκειται να προβληθούν ημερομηνίες στο UI καλύτερα να μετατρέπονται εκείνη τη στιγμή στο τοπικό timezone του χρήστη.

Όχι, δεν παίζει ρόλο η ρύθμιση του TIME_ZONE για το πώς αποθηκεύονται οι ημερομηνίες.
Οι ημερομηνίες αποθηκεύονται εσωτερικά με πολύ συγκεκριμένο, ανεξάρτητο της ρύθμισης TIME_ZONE τρόπο.
Το TIME_ZONE επηρεάζει την ερμηνεία και την παρουσίαση ημερομηνιών, όταν γίνεται είσοδος κι έξοδός τους.

Δείτε το documentation για τη ρύθμιση http://docs.djangoproject.com/en/dev/ref/settings/#time-zone.
Υπάρχει λίστα με τις επιτρεπόμενες τιμές. Η τιμή που ταιριάζει για Ελλάδα είναι η Europe/Athens.
Οπότε θέστε TIME_ZONE=Europe/Athens και φροντίστε το σύστημα να λειτουργεί σωστά με αυτή την τιμή.

Όχι, δεν έχεις δίκιο. Παίζει ρόλο και δημιουργεί προβλήματα:
http://code.djangoproject.com/ticket/2626

Υπάρχει κάποιος λόγος να μπλέξουμε με τοπικά timezones στο backend αντί να παίξουμε με την πιο universal λύση και να μετατρέπουμε τις ημερομηνίες στο timezone του κάθε χρήστη μέσω javascript μια μόνο φορά όταν θα τις εμφανίζουμε;

Dimitris Moraitis wrote:

Υπάρχει κάποιος λόγος να μπλέξουμε με τοπικά timezones στο backend αντί να παίξουμε με την πιο universal λύση και να μετατρέπουμε τις ημερομηνίες στο timezone του κάθε χρήστη μέσω javascript μια μόνο φορά όταν θα τις εμφανίζουμε;

Δημήτρη, το να μην τρέχει ένα πρόγραμμα με την αναμενόμενη ρύθμιση για timezone, ή το να σπάει αν η ρύθμιση timezone δεν είναι συγκεκριμένη, γενικά είναι παράξενο.

Καταλαβαίνω ότι το Django έχει κάποιου είδους συμπεριφορά που μας επηρεάζει σε σχέση με το timezone, αλλά:
α) όταν κανείς θέτει το TIME_ZONE=UTC επηρεάζει το timezone όλων των διεργασιών που εκτελούνται από το Django, οπότε αυτό μπορεί να δημιουργήσει προβλήματα και δεν υπάρχει λόγος να το κάνουμε εκτός αν...
...β) υπάρχει τεκμηριωμένη ανάγκη ότι δημιυργείται κάποιο πρόβλημα που δεν μπορεί αν διορθωθεί στον κώδικα γιατί είναι εσωτερικό του Django.

Καταλαβαίνω από το ticket 2626 του Django που έστειλες, κι από αρκετό ψάξιμο που έκανα χθες ότι η υποστήριξη για timezones στο Django είναι ελλιπής και ασυνεπής σε κάποια σημεία, αλλά ακόμη δεν μου είναι προφανές γιατί το πρόγραμμά μας σκάει ή τέλος πάντων δυσλειτουργεί αν δεν είναι TIME_ZONE=UTC. Οπότε, αν είναι να κάνουμε την αλλαγή, πρέπει να απαντηθούν τα εξής δύο σημεία:

α) ποιο είναι συγκεκριμένα το πρόβλημα που έχετε με τα timezones; τι θα γίνει, ποια γραμμή του κώδικα θα σκάσει, ποια γραμμή δεν κάνει το αναμενόμενο αν timezone=America/Chicago ή ξέρω γω τι άλλο; εδώ χρειάζεται ένα συγκεκριμένο σενάριο ασυνέπειας.

β) αν είναι να απαιτείται TIME_ZONE=UTC για να παίξει σωστά το πρόγραμμα [αυτό πρέπει να προκύψει από το (α)], αυτό πρέπει να τεκμηριωθεί πάααρα πολύ έντονα σε πολλά διαφορετικά σημεία. Αλλά επειδή είναι παράξενο να μη δουλεύει καν το πρόγραμμα αν το timezone δεν είναι σωστό, ας δούμε πρώτα το (α) και βλέπουμε.

Επειδή το ISO8601 είναι πολύ γενικό, καλό είναι να χρησιμοποιηθεί ένας parser που υποστηρίζει γενικά το πρότυπο. Προτείνω την python-dateutil, η οποία κάνει parse πολλές διαφορετικές μορφές, δείτε: http://niemeyer.net/python-dateutil και είναι και στο Squeeze.

Επίσης, δεν γίνεται η ορθότητα της εφαρμογής να εξαρτάται από το TIME_ZONE.
Οπότε, θα αλλάξει ο handler ώστε να παίρνει ό,τι ISO8601 νά'ναι, να το κάνει UTC, και μετά να το μετατρέπει σε local (naive) datetime και να το συγκρίνει.

Το αναλαμβάνει ο [verigak].

Μετά από offline συζήτηση με [verigak], καταλήξαμε ότι αυτό είναι πολύ δύσκολο να υλοποιηθεί σωστά.
Τα Django backends έχουν διαφορετική συμπεριφορά [η PostgreSQL καταλαβαίνει timezones, οι υπόλοιποι όχι], ticket http://code.djangoproject.com/ticket/2626 του Django. Οπότε, το API δεν μπορεί με αξιόπιστο τρόπο να ξέρει ότι γράφονται πάντα UTC ημερομηνίες οι οποίες επιστρέφονται πάντα με αυτόν τον τρόπο.

Αλλά και να αποφασίζαμε ότι πάντα αποθηκεύουμε UTC ώρες, το auto_now_add και το auto_now πάνε και γράφουν μόνα τους local ώρες.

Οπότε: επειδή θέλουμε να είμαστε ανεξάρτητοι από το db backend, κι επειδή τα auto_now κ.λπ. είναι πράγματι πολύ χρήσιμα, το API [και μόνο το API] θα τρέχει με TIME_ZONE = 'UTC'.

Το κάνω resolve. Πρέπει να προστεθεί ανάλογο σχόλιο στο settings.py, ότι το TIME_ZONE πρέπει να τίθεται σε 'UTC'.

Δεν υπάρχει αξιόπιστος τρόπος το API implementation να λειτουργεί με πολλαπλά db backends και να μπορεί να αποθηκεύσει σε UTC, γιατί η συμπεριφορά αλλάζει ανάλογα με το backend. Επιπλέον, τα auto_now, auto_now_add χρησιμοποιούν πάντα τοπικές ώρες.

Η υλοποίηση του API απαιτεί TIME_ZONE='UTC', το κλείνω.