-Original Message-
> From: pmacct-discussion [mailto:pmacct-discussion-boun...@pmacct.net]
> On Behalf Of Vaggelis Koutroumpas
> Sent: Tuesday, May 31, 2016 12:41 PM
> To: pmacct-discussion@pmacct.net
> Subject: Re: [pmacct-discussion] MySQL Timezone handling
>
> Thanks for you
Thanks for your suggestion guys,
How do you propose to work with UTC? Should the OS' clock run in UTC or
only the MySQL server?
I just feel that running the server clock in UTC will be a bit
uncomfortable having to constantly translate the dates from UTC to
UTC+2/3 while working with logs etc.
+1 to storing your application data in UTC.
+1. Your server and storage backend should be set to UTC. This is the
only way to assure consistency of timestamped data.
Zoning should be make on the frontend side.
--
Raphael Mazelier
___
> I look forward to any thoughts about data types. Personally, the very
> first reaction this trigger is: the backend of the accounting system
> should be set to a timezone that does not change during the year and,
> even more ideally, to UTC. UTC is ideal because it helps when stuff is
> spanning
Hi Vaggelis,
I look forward to any thoughts about data types. Personally, the very
first reaction this trigger is: the backend of the accounting system
should be set to a timezone that does not change during the year and,
even more ideally, to UTC. UTC is ideal because it helps when stuff is
Hello,
I am using nfacct to process flows from our routers and store them in a
mysql database for processing and visualization.
I have a 'daily' table for storing the daily traffic for each IP. I've
set sql_history to 1d to store one record per day per IP.
This worked fine for months. Each
