Hi there,
Sorry to bother you all again.
It's really wired. I have changed time_zone in nav.conf and all time is correct on the front page.
But only the Service state alert's start time and end time is showing in UTC timezone.
I went through database and confirmed those time was recorded by UTC timezone, as below:
SQL: select * from manage.alerthist
As you can see, the other’s alert in thresholdState is correct.
I also looked into python code,
In python/nav/models/event.py
class AlertQueue(models.Model, EventMixIn):
time = models.DateTimeField()
class AlertHistory(models.Model, EventMixIn):
start_time = models.DateTimeField()
I changed those code to models.DateTimeField(default=dt.datetime.now), but still got same issue.
I was just wondering has anyone run into the same problem?
Cheers.
Bruce
On Tue, 12 Sep 2017 22:24:08 +1000 "Bruce Zhang" brucezhang2010@gmail.com wrote:
It's really wired. I have changed time_zone in nav.conf and all time is correct on the front page.
But only the Service state alert's start time and end time is showing in UTC timezone.
I think this problem is easily explained, and potentially easily fixed.
The timezone setting in `nav.conf` only applies to timestamps generated in Python code.
However, the component that produces serviceState alerts, servicemon, doesn't generate the timestamps in Python code. Servicemon is one of the oldest pieces of code in NAV (pre Django-era), and uses pure SQL to insert events into the database. It hands the timestamp generation over to PostgreSQL itself, which means that the timezone is decided by PostgreSQL, not by NAV.
I guess the easy fix would be to have servicemon produce an explicit timestamp to insert, instead of leaving it up to PostgreSQL.
All timestamp fields in NAV's PostgreSQL schema use the `TIMESTAMP WITHOUT TIME ZONE` data type. The more complicated (and probably more long-term) solution to problems like this would be to change all those fields to `TIMESTAMP WITH TIME ZONE`.
I'm out travelling atm; I suggest reporting this bug at [1], so we don't forget about it :)
[1] https://github.com/UNINETT/nav/issues/new
Hi Morten, You are champion! Changed PostgreSQL Timezone and it's fixed. I never thought of the timezone was coming from Postgres. :)
Bruce
-----Original Message----- From: Morten Brekkevold [mailto:morten.brekkevold@uninett.no] Sent: Thursday, 14 September 2017 9:42 PM To: Bruce Zhang brucezhang2010@gmail.com Cc: nav-users@uninett.no Subject: Re: ServiceState alert showing in UTC timezone
On Tue, 12 Sep 2017 22:24:08 +1000 "Bruce Zhang" brucezhang2010@gmail.com wrote:
It's really wired. I have changed time_zone in nav.conf and all time is correct on the front page.
But only the Service state alert's start time and end time is showing in UTC timezone.
I think this problem is easily explained, and potentially easily fixed.
The timezone setting in `nav.conf` only applies to timestamps generated in Python code.
However, the component that produces serviceState alerts, servicemon, doesn't generate the timestamps in Python code. Servicemon is one of the oldest pieces of code in NAV (pre Django-era), and uses pure SQL to insert events into the database. It hands the timestamp generation over to PostgreSQL itself, which means that the timezone is decided by PostgreSQL, not by NAV.
I guess the easy fix would be to have servicemon produce an explicit timestamp to insert, instead of leaving it up to PostgreSQL.
All timestamp fields in NAV's PostgreSQL schema use the `TIMESTAMP WITHOUT TIME ZONE` data type. The more complicated (and probably more long-term) solution to problems like this would be to change all those fields to `TIMESTAMP WITH TIME ZONE`.
I'm out travelling atm; I suggest reporting this bug at [1], so we don't forget about it :)
[1] https://github.com/UNINETT/nav/issues/new
-- mvh Morten Brekkevold UNINETT AS
-
Bruce Zhang -
Morten Brekkevold