Issue #1703: Fix the input date timezone for log_calls start, endtime

[abdulazizali77]

@otsakir Apparently this is expected behaviour in Angular One recommended way is to fix the timezone as suggested here http://stackoverflow.com/questions/30236499/date-issue-in-angular As im absolutely new to Angular, i do think the fix is a reasonable approach. One other approach could also to introduce a timezone dropdown.

Additionally i have not made changes to logs-messages, notifications, recordings, transcriptions. They all have date inputs would presumably have the same defect. What do you think?

[abdulazizali77]

@otsakir I blindly used the timezone '-200' without really understanding Angular's call flow (the -0200 shift was for the SO poster's specific tz, he's in Brasil!)

Analysis: -The date input will be serialized by interception when it is used in the GET     -If the timezone is not set in ng-model-options or date format, the client/browser tz willbe used, in my case GMT     -If a timezone had been set, the supplied date will be converted -The prefiltered date input will then be intercepted     -At Angular.js:10125 stringify() - date will still be local, GMT in my case     -At Angular.js:1043 toJson() - date will still be local, GMT in my case     -At Angular.js:1048 toJson() - date will be passed to JSON.stringify and this will implicitly convert the local/GMT date to UTC. Javascript Date class doesnt take any timezone information.     -At Angular.js:1013 toJsonReplacer() - the date passed in is already converted to UTC.

Possible fixes:

1. Fix the local date in browser to timezone UTC with ng-model-options, so that Angular wont do any conversion. 1b) Supply additional dropdown to allow selection of timezone with UTC defaulted.
2. Set Angular default timezone from UTC to the local browser timezone. There doesnt seem to be an easy constant or global exposed to do this. Might have to figure out the dateFilter filter.

Conclusions: For now i would go for 1). Ive pushed new commits to reflect this.

What do you think?

[deruelle]

@otsakir did you miss replying ?

[otsakir]

@abdulazizali77 , i've run an investigation on how StartTime filter is treated from the browser DatePicker up until it's injected in mybatis sql scripts. Let me share my findings:

I'm currently in a GMT+3.00 timezone.

Before the patch:

1. I pick start date 2017-03-27
2. The date transmitted is 2017-03-26T21:00:00.000Z. This makes some sense. The date is converted to GMT time.
3. The date is parsed by rcomm here https://github.com/RestComm/RestComm-Connect/blob/1f5637cb21dfba9d324188dfab4ba5482fd36c08/restcomm/restcomm.dao/src/main/java/org/restcomm/connect/dao/entities/CallDetailRecordFilter.java#L75-L75 and the parsed value is: Sun Mar 26 00:00:00 EET 2017. So it seems that rcomm just takes the yyyy-mm-dd part and interprets it as being of the local (in terms of rcomm installation machine) timezone.
4. The generated DB query includes: AND "start_time" >= ? ('ACae6e420f425248d6a26948c17 ...,TIMESTAMP'2017-03-26 00:00:0 ...) Considering that there is no timezone information stored in the db, server treats all dates as local. So, the date 2017-03-26 00:00:0 will be treated as the midnight of the 25-to-26 of March in the local time of the server.

So, this will result in getting all calls created after 2017-03-26 00:00:0 in server local time.

After the patch:

1. I pick start date 2017-03-27
2. The date transmitted is 2017-03-27T00:00:00.000Z
3. The date is parsed by rcomm when creating the filter resulting to: Mon Mar 27 00:00:00 EEST. 2017. Note the change in timezone. This seems wrong.
4. The generated DB query includes: AND "start_time" >= ? ('ACae6e420f425248d6a26948c17 ...,TIMESTAMP'2017-03-27 00:00:0 ...)

So, this will result in returning all calls that were created after 2017-03-27 00:00:0 in server local time.

Also, note the following:

• Rcomm uses no timezone information when storing the dates (at least in hsql that i've checked). Local time is used and NOT GMT.
• Twilio API states that StartTime for calls is returned in GMT - https://www.twilio.com/docs/api/rest/call. I suppose that since a Call's StartTime is returned in GMT, the same convention is assumed when querying calls.

It looks that both versions of the code are wrong. Your patch sends the time in GMT which complies with twilio but won't produce the records the user intended to see since the StartDate is stored in server local time.

I was thinking of the following:

a. Keep client-side code as it is. The date-picker will return midnight time of the date selected in the user's timezone. It will then convert it to GMT before sending. No shift takes place here. Just chaning the timezone. When i select 2017-03-27 i expect to see the calls initiated after 2017-03-27 00:00:00 in my time. b. CallDetailRecordFilter should be updated so that it properly parses StartTime and not just taking yyyy-mm-dd part of it and treating that as server local time. So, the net result is that user's browser time will be converted to server's time with both timezones taken into account. c. The resulting calls will (hopefully) be those that actually started after 2017-03-27 00:00:00 in terms of user's time.

Please tell me what you think.

[gsaslis]

@abdulazizali77 is this PR still valid? Trying to run some housekeeping. Plz let me know if I should keep open.

[abdulazizali77]

@gsaslis Unfortunately someone needs to reverify the issue this PR is supposed to fix, My initial thought was that my small change addressed/fixed the issue, however @otsakir did not agree/found further issues. I unfortunately lost track of the problems for or against, Orestis care to comment?