search

vergoh / vnstat

vnStat - a network traffic monitor for Linux and BSD
GNU General Public License v2.0
1.41k stars 120 forks source link

Changes in time zones can cause data misalignment. #204

Closed wc7086 closed 3 years ago

wc7086 commented 3 years ago

Is it possible to use unix timestamp to record the time so that the data will not be disrupted by the system time zone.

If it is not convenient to change, please also add an option to record the time with uninx timestamp.

vergoh commented 3 years ago

Using unix timestamps for the data and then recalculating it depending on the time zone isn't possible as only the 5 minute resolution data would be on a short enough interval for doing that. In comparison, the daily level data is already as days in the database so there's no way of extracting the necessary details that would be needed for recalculating the time zone. While it could, in theory, be possible to store all the data only at a 5 minute resolution, that would require a much larger database and I wouldn't expect that to fit well with many current users.

As you suggested, adding an option for storing the data always in UTC could be doable, likely without too much extra effort. I'll have to first however check if it's even practical to implement within the code or would it be easier to just adjust the time zone for the daemon startup for example from the systemd service file. The time zone the daemon sees defines what is written in the database during runtime. Obviously, all this assumes that the RTC is following UTC instead of being adjusted depending on the used time zone.

wc7086 commented 3 years ago

Using unix timestamps for the data and then recalculating it depending on the time zone isn't possible as only the 5 minute resolution data would be on a short enough interval for doing that. In comparison, the daily level data is already as days in the database so there's no way of extracting the necessary details that would be needed for recalculating the time zone. While it could, in theory, be possible to store all the data only at a 5 minute resolution, that would require a much larger database and I wouldn't expect that to fit well with many current users.

As you suggested, adding an option for storing the data always in UTC could be doable, likely without too much extra effort. I'll have to first however check if it's even practical to implement within the code or would it be easier to just adjust the time zone for the daemon startup for example from the systemd service file. The time zone the daemon sees defines what is written in the database during runtime. Obviously, all this assumes that the RTC is following UTC instead of being adjusted depending on the used time zone.

Okay, I didn't think about it. The option you mentioned to always record in UTC is also a good choice.