@ntozier additional information on this issue.
We had closed several tickets on 30/4/2019 and they were all being displayed when the date was in fact 1/5/2019.
We noticed that by 2pm on 1/5/2019 that the date had rolled over to match our day.
However coming in today 2/5/19 I can see that it is displaying closed today tickets for 1/5/19

Maybe a daft question here, but is the time (and timezone setting) on the server itself correct??

Also, you're going to get asked to upgrade osTicket to 1.12... 1.11 is unsupported now!

Server Timezone is correct, OSticket is correct but this queue is incorrect.

I am in the process of testing 1.12 in accordance with our companies user acceptance testing guidelines

    Also what is your MySQL server timezone set to?

    LewisHackfath
    hmm, that all looks good, have you tried changing the timezone and see if it's taking effect, then change it back?

      The entire server has been restarted several times since the upgrade to 1.11 to install other updates.

        I upgraded OSticket from 1.10.4 -> 1.11
        This problem also exists in 1.12

        Try setting the actual timezone in mysql instead of relying on the "server"

        I have changed the MYSQL timezone to '+10:00' and performed select now() which is showing the correct date/time.
        But OSTicket Closed today still shows yesterdays results.

        5 days later

        I have now upgraded to 1.12 and this is still occurring.

        2 months later

        Hi @ntozier ,

        I have worked out what the cause of this is.
        In the bootstrap.php file you do a number of checks against the php.ini default timezone starting on line 35.
        However after all of that you then set the default timezone to UTC no matter the outcome of the checks. this is done on line 46

        commenting out line 46 fixes my issue with the closed today queue being incorrect but it then creates problems with the lock system where no user can post a reply to tickets.