Page 1 of 1

AD2PI zone events log in UTC time instead of local timezone

PostPosted: Sun Jan 22, 2017 1:08 pm
by m_listed
I set my Raspberry Pi's time zone to my local zone, and this seems to be working for the "App" and "Live" logs, but for the "Events" log, the AD2PI app continues to log every event according to UTC time instead of local time. How can I make it so these events are logged per local time as well?

Re: AD2PI zone events log in UTC time instead of local timez

PostPosted: Sun Jan 22, 2017 2:01 pm
by kevin
Login via ssh and set your date/time, we ship it as UTC by default - https://www.cyberciti.biz/faq/howto-set ... nd-prompt/

The python event stores the current date/time in the database and on rendering the datatable it is passed through a javascript function to normalize to your localtime - so I would check that date/time parameters are set correctly. I suggest the timedatectl method

Event log timestamps are converted using the following function:
Code: Select all
        function RenderDateLocal(oObj)
        {
            //parse date from python to format Date object understands
            var match = oObj.aData[oObj.iDataColumn].match(/^(\d+)-(\d+)-(\d+) (\d+)\:(\d+)\:(\d+)$/);
            var localDate = new Date(match[1], match[2] - 1, match[3], match[4], match[5], match[6]);
            //take care of timezone offset in minutes to hours by negating and then adding to the hours
            var tzo = (localDate.getTimezoneOffset()/60) *-1;
            localDate.setHours(localDate.getHours() + tzo );
            //reformat date for consistency
            var dateStr = localDate.getFullYear() + "-" + (localDate.getMonth() + 1) + "-" + localDate.getDate() + " " + localDate.toLocaleTimeString();
            return dateStr;
        }

Re: AD2PI zone events log in UTC time instead of local timez

PostPosted: Sun Jan 22, 2017 6:17 pm
by m_listed
I don't think JavaScript has a central place where the timezone is set, but timedatectl nevertheless shows the correct local time and UTC time because I did "sudo dpkg-reconfigure tzdata" and set it to my local timezone. The Alarmdecoder web app still shows all zone fault and restore etc. events as UTC though. It was working correctly (i.e. logging in local time) before the latest update though.

Re: AD2PI zone events log in UTC time instead of local timez

PostPosted: Sun Jan 22, 2017 10:56 pm
by kevin
All right, please file an issue on the github project and it'll be added to the list of things to investigate/fix on another release.

The JavaScript above uses your local clientside computer's time data to calculate based off of time/date from event in datatable

Re: AD2PI zone events log in UTC time instead of local timez

PostPosted: Wed Mar 01, 2017 5:09 pm
by billfor
Looks like fnRender is ignored if used, so the RenderDataLocal never gets called. fnrender has been deprecated from jQuery so you have to use mRender going forward.

The "Live" section never had the problem because the code doesn't actually pull the value from a database -- it just stamps it with your currently time. So there is no transformation there.

Do you want me to file a bug?

fyi if you want to fix it temporarily, find the events.html file and change this line:
{"fnRender": RenderDateLocal },
to
{"mRender": RenderDateLocal },


now because mRender works differently, you also have to change the rendering function.

change
function RenderDateLocal(oObj)
to
function RenderDateLocal(data,type,full)

and change the first line that has the regex matching to:

var match = data.match(/^(\d+)-(\d+)-(\d+) (\d+)\:(\d+)\:(\d+)$/);

Re: AD2PI zone events log in UTC time instead of local timez

PostPosted: Thu Mar 02, 2017 10:21 am
by kevin
billfor wrote:Looks like fnRender is ignored if used, so the RenderDataLocal never gets called. fnrender has been deprecated from jQuery so you have to use mRender going forward.

The "Live" section never had the problem because the code doesn't actually pull the value from a database -- it just stamps it with your currently time. So there is no transformation there.

Do you want me to file a bug?

fyi if you want to fix it temporarily, find the events.html file and change this line:
{"fnRender": RenderDateLocal },
to
{"mRender": RenderDateLocal },


now because mRender works differently, you also have to change the rendering function.

change
function RenderDateLocal(oObj)
to
function RenderDateLocal(data,type,full)

and change the first line that has the regex matching to:

var match = data.match(/^(\d+)-(\d+)-(\d+) (\d+)\:(\d+)\:(\d+)$/);


Looks like we stumbled upon this fix around the same time. I did it a little differently. Yes to the mRender step, but did not change prototype of RenderDateLocal at all

Code: Select all
        function RenderDateLocal(oObj)
        {
            //parse date from python to format Date object understands
            var match = oObj.match(/^(\d+)-(\d+)-(\d+) (\d+)\:(\d+)\:(\d+)$/);

            var localDate = new Date(match[1], match[2] - 1, match[3], match[4], match[5], match[6]);

            //take care of timezone offset in minutes to hours by negating and then adding to the hours
            var tzo = (localDate.getTimezoneOffset()/60) *-1;
            localDate.setHours(localDate.getHours() + tzo );

            //reformat date for consistency
            var dateStr = localDate.getFullYear() + "-" + (localDate.getMonth() + 1) + "-" + localDate.getDate() + " " + localDate.toLocaleTimeString();
            return dateStr;
        }



At any rate, this was due to an upgrade of the dataTables plugin that we use - and is fixed locally here - hopefully pushed to github sometime soon.

Thanks for your help!

Re: AD2PI zone events log in UTC time instead of local timez

PostPosted: Thu Mar 02, 2017 10:55 am
by billfor
Yeah the other arguments are thrown away but technically the definition of mRender calls for a 3 argument function so I just added them as per their spec. It was interesting that the Jquery developers decided to deprecate and nullify an old function rather than just leaving the behavior there for people who had used it. Anyway it works now -- was just annyoing the hell out me so had to fix it :-)