> 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.
Sounds like you don't have server in different time zones... believe me,
merging log data stored with local time from different time zones is no fun.
Another problem is the daylight saving time changes where data from 2 hours is
pushed into one or results in a one hour gap of data when some may be expected.
> How do you propose to work with UTC? Should the OS' clock run in UTC or
> only the MySQL server?
I recommend to work on backend systems with UTC only. Converting from and to
local or user time zone on the frontend only.
> Would running only MySQL in UTC timezone be sufficient?
I would say yes as long as client connections don't set their own time zone.
Regards,
Mario
> -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 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.
>
> Would running only MySQL in UTC timezone be sufficient?
>
>
>
> On 31/5/2016 11:40 πμ, raf wrote:
> >
> >
> >> +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.
> >
> >
>
>
> ___
> pmacct-discussion mailing list
> http://www.pmacct.net/#mailinglists
___
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists
