2009-05-19 3 views
6

Ho avuto qualche problema con un'applicazione Django dopo che l'ho distribuito. Io uso un mod-wsgi Apache + su un server ubuntu. Un po 'di tempo dopo il riavvio del server, il tempo passa a foobar, è sbagliato di circa -10 ore. Ho fatto una vista Django che assomiglia:datetime.now() nell'applicazione Django va male

def servertime(): 
    return HttpResponse(datetime.now()) 

e dopo riparto l'assistente e controllare l'URL che mostra che visualizza per la prima sembra a posto. Poi a un certo punto a volte dà il tempo giusto e qualche volta no e dopo dà sempre il tempo sbagliato. Tuttavia, l'ora del server è corretta.

Eventuali indizi? L'ho cercato su Google senza fortuna.

+0

Sono esattamente 10 ore? Potrebbe essere un problema di fuso orario. –

+0

Ho sperimentato anche lo stesso bug. Sembra che il metodo 'datetime.now()' sia calcolato una volta per tutte all'avvio del server ed è costante successivamente (per la data e non per le ore). Davvero un comportamento molto strano e inaspettato. Cercherò di configurare wsgi_mod in modalità daemon, come proposto nella risposta contrassegnata. E, in effetti, stavo anche eseguendo un'applicazione PHP nello stesso tempo ... – perror

+0

Questo era con Django 1.1 quindi probabilmente non è più un problema con il nuovo supporto per il fuso orario di Django. – Nixarn

risposta

5

Ho scoperto che il funzionamento di wsgi in demone funziona. Non so perché, ma è successo. Sembra che alcuni dei processi appena creati perdano tempo.

+6

Molto probabilmente perché stavi eseguendo altre applicazioni Web contemporaneamente in Apache, come PHP, e quell'applicazione stava cambiando il fuso orario come un altro valore e avvincente con l'applicazione Django. Questo problema è documentato nella documentazione di mod_wsgi all'indirizzo http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Timezone_and_Locale_Settings. –

6

Posso vedere anche il tuo urls.py?

comportamenti simili mi perplessi una volta prima ...

Che si è rivelato essere stato il modo in cui la mia urls.py chiamato la vista. Python ha eseguito una volta il datetime.now() e l'ha memorizzato per le chiamate future, senza mai chiamarlo di nuovo. Questo è il motivo per cui gli sviluppatori di django hanno dovuto implementare la possibilità di passare una funzione, non una chiamata di funzione, al valore predefinito di un modello, perché richiederebbe la prima chiamata della funzione e la userebbe fino a quando Python non verrà riavviato.

Il tuo comportamento sembra che la prima volta sia corretta perché è la prima volta che viene richiamata la vista. A volte non era corretto perché aveva di nuovo la stessa data. Quindi è stato corretto di nuovo in modo casuale perché il tuo apache probabilmente ha avviato un altro processo di lavoro per questo, e la follia probabilmente accade quando ti viene rimbalzato tra quale processo stava gestendo la richiesta.

0

potrebbe essere necessario specificare il tipo di contenuto in questo modo

def servertime(): 
    return HttpResponse(datetime.now(), content_type="text/plain") 

un'altra idea:

esso potrebbe non funzionare a causa datetime.now() restituisce un oggetto datetime. Prova questo:

def servertime(): 
    return HttpResponse(str(datetime.now()), content_type="text/plain") 
1

Forse il server sta valutando l'datetime.now() all'avvio del server, provare a fare è pigro attraverso un modello o utilizzare una variabile nella vista.

Dai un'occhiata a questo blog post.

1

Django imposta il fuso orario del sistema in base alla variabile di impostazione TIME_ZONE. Questo può portare a tutti i tipi di confusione quando si eseguono più istanze di Django con diverse impostazioni TIME_ZONE.

Questo è ciò che Django fa:

os.environ['TZ'] = self.TIME_ZONE 

La risposta di cui sopra:

"Ho trovato che mettere WSGI in modalità demone funziona"

non funziona per me. ..

Penso che non utilizzerò più il django integrato in TIME_ZONE.

2

datetime.now() è probabilmente in fase di valutazione una volta, quando viene eseguita l'istanza della classe. Prova a rimuovere la parentesi in modo che la funzione datetime.now venga restituita e THEN abbia valutato. Ho avuto un problema simile con l'impostazione di valori predefiniti per i miei DateTimeFields e ho scritto la mia soluzione here.

0

tenta di impostare il fuso orario (variabile TIME_ZONE) in settings.py

che ha lavorato per me.