Solved Today Call Log Disappeared after today update.

[YiannisH_3CX]

Thank you for the update,
Please note that we are looking into the issue and i will update you once we have something.
I will let you know if we need additional data.

 

[jimbo59]

For those on the East Coast please login at 7pm and see if the logs for the day appear.
Central see if they appear at 6.
For Mountain at 5
And Pacific at 4
I think it has something to do with GMT date and a filter in the log.

Furthermore the web clients show the correct logs.

 

[Sopock]

Yes, something like this:
For timestamp with time zone, the internally stored value is always in UTC (Universal Coordinated Time, traditionally known as Greenwich Mean Time, GMT). An input value that has an explicit time zone specified is converted to UTC using the appropriate offset for that time zone. If no time zone is stated in the input string, then it is assumed to be in the time zone indicated by the system's TimeZone parameter, and is converted to UTC using the offset for the timezone zone.

npgsql(#1469):
What about the multi-tier applications? Application server connects to the database to process the client requests. App-server threads belong to different user sessions and have different time zones. So it's just pointless to convert timestamps using the app-server's time zone info.

I'm a programmer and my guess is it's a filter on the call log that is not correct. The calls and times and dates are there and correct, but they don't display in the log until after 1600.

Admin in any time zone should see logs in local time

Alternatively, if you're building your UI with JavaScript (e.g., in an Angular/React/etc application) just send the dates from the server to the client in UTC, and then have client-side logic for displaying it in the local date format and offset.

 

[MarkNance]

Same issue here after SP3 update on ALL of our customers PBX installs.

 

[Flash99]

Same issue here after SP3

 

[loyer]

I am also seeing this issue. Glad to know it isn't just me!

 

[AH2]

... updated, saw a reply at last ..

My issue persists on 2 different servers.

Thanks for the update.

 

[AH2]

Can you please let me know the know the following so we can further investigate the issue:

• The timezone of the PBX server.
• Operating system the PBX is running on
• How are you accessing the server (directly from the server, RDP, Management console from a remote location etc.)

Debian - Latest version - Google Cloud Hosted
Web Console
GMT -5

 

[Richard Flick]

This snippet from Calllogs.frs shows the time conversion:

public DateTime LocalTime(DateTime dt)
        {
            if(dt.Kind == DateTimeKind.Unspecified)
                dt = DateTime.SpecifyKind(dt, DateTimeKind.Utc);
             
            if(dt.Kind == DateTimeKind.Local)
                dt = dt.ToUniversalTime();
         
            return DateTime.SpecifyKind(TimeZoneInfo.ConvertTime(dt, TimeZoneInfo.Utc, currentTZ), DateTimeKind.Local);
        }

It seems to be defaulting to GMT perhaps due to faulty timezone data?

 

[giwm]

This is the appropriate time to say, "+1", right?

 

[3CXusername]

Held on to 15.5 SP1 after reading about SP2 conferencing changes. Thanks to the community bringing this SP3 issue up before it burns the rest of us.

Looking forward to 3CX resolving so we can upgrade our instances. Hopefully before SP4.

 

[jimbo59]

It would be nice to hear from them "we've duplicated the problem and expect a patch within a few days," but so far nothing.

 

[YiannisH_3CX]

We are aware of the issue and we are looking into it. At the moment we are trying to figure out the extent of the issue as it does affect all time zones.

 

[Kevnich2]

I have two systems, one on debian 9 and another on debian 8. The debian 9 is literally a fresh install from a few days ago. Both are running the latest v15.5 Update 3. Both systems are setup for eastern time in both 3cx and the server.

Both the call log and call reports both only show things related to the day prior. Since this threat is specific to the call log, I'll be more specific to this. Any day, prior to what seems to be around 17:00 eastern, the call log will ONLY show call history for the day prior, and there are no filters in place. This happens on BOTH systems.

During the evening around 18:00 or so, not sure why this is happening but all of a sudden something happens with the call log and it shows all the calls for that day and updates real-time. If I call into a number on the 3cx system, I wait about 5 seconds and it shows that call in the call log. If anyone from 3cx would like a backup configuration or even a login to take a look at these systems yourself for troubleshooting, I'll be more than willing to help where i can. This "bug" whatever is causing it, needs fixed. I use the call log alot during the day for troubleshooting and to see how busy the incoming calls are and it doesn't help me at all if this doesn't reflect the current day until 18:00 or later.

 

[jimbo59]

Your customers need a fix soon. This should be a fix a programmer could crank out in a few hours.

What gives?

 

[cometmth]

FWIW, I had this issue as well. Debian 8, America/Chicago, access via https FQDN. I just moved my install from a local citrix xenserver to AWS on Debian 9. Prior to installing 3cx on my ec2 instance, I set the timezone using timedatectl. After the install/restore finished, I was able to see this morning's calls in the call log! It's a special case for sure, but hopefully it helps 3CX figure it out.

 

[Sopock]

Maybe that instance is (not) using UTC as HW clock?
timedatectl | grep local

 

[cometmth]

# timedatectl | grep local
RTC in local TZ: no

And today it's showing yesterday's calls. So it worked immediately after fresh install and restoring the backup, and broke the next day.

 

[Richard Flick]

We are aware of the issue and we are looking into it. At the moment we are trying to figure out the extent of the issue as it does affect all time zones.

Is there a fix?

 

[AH2]

This should not be something out of this world, and from what it seems, the community has given the answer to the problem, should try to push a small update, this is annoying on a day to day basis for everyone involved.