That seems like a nice safe approach for others who need to do the same thing.
I ended up doing something like this with a few side trips involved. Stop weewx backup weeewx db Setting the clock_check value really low change timezone on the host start weewx check logs for errors revert clock_check value restart weewx. Thanks for the suggestions! Blake On Sunday, October 16, 2022 at 7:57:26 PM UTC-7 vince wrote: > I'd probably approach it ala: > > - stop weewx and back up the db(s) > - probably set debug=1 in weewx.conf to make logs more helpful > - set the os system timezone as desired. I think the magic > incantation is 'sudo timedatectl set-timezone "America/Los_Angeles" and > if you run a full desktop there's a gui utility to do this as well. One > howto link is > https://tecadmin.net/how-to-change-timezone-on-ubuntu-20-04/ - your > syslog should show the date+time changed to your local timezone > immediately. > - I'd then set the console timezone manually at the Davis console. > The manual is at > > https://www.weathershack.com/products/davis/manuals/vantage-pro2-console-manual.pdf > > which is pretty clear > - I'd personally shut the system down (full poweroff via 'sudo > poweroff' or equivalent) and then power it back up > - The os should set its clock via systemd (or ntp if you have that > installed) and weewx should wait until it has sane time before starting. > The logs will tell you what's going on. > - my recollection is weewx has no notion of timezone, but it's unclear > to me what datestamps (if there are any) are in the records stored in the > datalogger. Given that the above should take only a minute or three to > accomplish, I'd hope you won't lose any observations....but that's why we > take the backups just.in.case. > > > On Sunday, October 16, 2022 at 6:00:16 PM UTC-7 [email protected] > wrote: > >> OK I (backed up the db again) set the system timezone back to US/Pacific >> and then set the following down to 30 sec. >> >> [StdTimeSynch] >> clock_check = 30 >> >> I got these messages on the log shortly after service start. >> >> Oct 16 17:52:49 wx python3[780]: weewx[780] INFO weewx.engine: Clock >> error is -24.57 seconds (positive is fast) >> Oct 16 17:52:49 wx python3[780]: weewx[780] INFO weewx.drivers.vantage: >> Clock set to 2022-10-16 17:52:50 PDT (1665967970) >> >> The "* WARNING weewx.engine: Ignore historical record" * messages have >> now stopped on the log.. >> >> I ended up with some bad data in the db from what the reports show. >> >> On Sunday, October 16, 2022 at 5:32:29 PM UTC-7 Greg Troxel wrote: >> >>> >>> Blake Garner <[email protected]> writes: >>> >>> > I want to change the timezone from UTC to Pacific time display in >>> local >>> > time on my weewx website. From reading, it seems that weewx uses the >>> system >>> > time and it's not configurable at the application. After changing my >>> system >>> > timezone to US/Pacific I'm seeing this message spew in the logs. For >>> now I >>> > flipped the timzone back until I have a better idea of what's going >>> on. >>> > >>> > Oct 16 23:24:38 wx python3[2833293]: *weewx[2833293] WARNING >>> weewx.engine: >>> > Ignore historical record: {'dateTime': 1665970800, 'usUnits': 1, >>> >>> $ TZ=UTC date -r 1665970800 >>> Mon Oct 17 01:40:00 UTC 2022 >>> >>> So without knowing what the highest value is, hard to interpret. >>> >>> >>> >>> I'm not totally clear on this, but I think what's happening is: >>> >>> database is always in UTC >>> >>> VP2 does not have a protocol that is always UTC and display localtime; >>> it fundamentally operates in local time >>> >>> driver infers VP2 clock time as local time, in this case UTC >>> >>> Yes, report generation follows timezone >>> >>> My weewx machine (RPI3, NetBSD 9, with VP2) is set to EST5EDT. >>> >>> >>> So therefore I guess that your VP2 is running in UTC, even if it thinks >>> it is s PST8PDT which might mean that the data in the database is >>> correct, but >>> >>> - the time on the console is 7 hours ahead (now) >>> - the daily high/low values are not for localtime midnight-midnight >>> - the data in the database is actually right. >>> >>> - I have no idea what's going on with console DST settings. >>> >>> To recover, I wonder if you need to somehow pause the console for 7h. >>> Or if just changing the time on the console as you flip the TZ is >>> enough. >>> >>> Or if I'm wrong about labeling on database records being ok, and you >>> need to do surgery. >>> >>> I'm sure someone has had this problem; definitely wait for better >>> advice, but this may give you things to think about and try to >>> understand, even if my guesses are a bit off. >>> >>> Definitely back up your database right now, and also before you tried to >>> change the TZ the first time :-( >>> >> -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/24fc1757-03da-47b5-bd6e-fa8411bc281an%40googlegroups.com.
