We can do next way, in the user's request we put a localtime of user
(JavaScript) or a different between servertime and usertime. Base on
this information we can make a correct request with modifed date/time.
Wbr,
Alexandr
P.S. can we continue our talk in homer-dev ? :-) let make some activites
there .
8/15/2012 5:26 PM, Douglas Hubler wrote:
> Update: this is actually a bad idea. My initial tests were flawed,
> this does not work. You need to leave mysql in system time zone and
> when inserting records in capture server, save time using local time
> (i.e. localtime) and not utc (i.e. gmtime).
>
> This means if the timezone was ever changed on a system, all the dates
> in the data would be off.
>
> On Tue, Aug 14, 2012 at 11:49 AM, Douglas Hubler <
dhu...@gmail.com> wrote:
>> After debugging a few issues, related to time zones, I made the decision to
>> put mysql into UTC by default.
>>
>> File: /etc/my.cnf
>> ----------------------
>> [mysqld]
>> default-time-zone='+00:00'
>> ...
>>
>> Even though the system's timezone is not UTV. I do set timezone in php (to
>> match system) and so far all that works. I did run into an issue were
>>
statistic.pl executes a query and does not account for UTC. I'll add
>> parameter to
statistics.pl script w/default to system TZ, but allow it to be
>> configurable. I might have a long road ahead tracking down issues. Just
>> thought I'd share in case someone had input. No response nec.
>>