You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am running NSOT in an lxd container which has UTC as its timezone.
When creating or editing anything in the NSOT GUI, the changelog tells me that the change happened "5 hours ago".
I believe this is to do with the Django legacy default TIME_ZONE which is America/Chicago
I suggest that the default generated nsot.conf.py have TIME_ZONE = 'UTC', because this is what Django does for new projects:
Since Django was first released with the TIME_ZONE set to 'America/Chicago', the global setting (used if nothing is defined in your project’s settings.py) remains 'America/Chicago' for backwards compatibility. New project templates default to 'UTC'.
When I change this setting, all the existing changes still say they happened "5 hours ago", but new changes are "a few seconds ago". It appears that dates are stored in local time.
A modern Django project will have USE_TZ=True and maybe that ought to be used as well.
The default settings.py file created by django-admin startproject includes USE_TZ = True for convenience.
This might mean that timestamps are stored in the database as UTC, regardless of the display timezone, which would be better.
The text was updated successfully, but these errors were encountered:
I am running NSOT in an lxd container which has UTC as its timezone.
When creating or editing anything in the NSOT GUI, the changelog tells me that the change happened "5 hours ago".
I believe this is to do with the Django legacy default TIME_ZONE which is
America/Chicago
I suggest that the default generated
nsot.conf.py
haveTIME_ZONE = 'UTC'
, because this is what Django does for new projects:When I change this setting, all the existing changes still say they happened "5 hours ago", but new changes are "a few seconds ago". It appears that dates are stored in local time.
A modern Django project will have USE_TZ=True and maybe that ought to be used as well.
This might mean that timestamps are stored in the database as UTC, regardless of the display timezone, which would be better.
The text was updated successfully, but these errors were encountered: