Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion

osTicket v1.10 (stable) and Maintenance Release v1.9.15 are now available! Go get it now

[resolved] Strange inconsistent time problem (1.9.12)

After a recent server move, I am running into an inconsistency with the timestamps inside the osTicket database. I have attached a screenshot illustrating the problem. Basically, the timestamp for the creation of the ticket is slow by four hours, but the last_modified timestamp when I assigned the ticket (which happened only a few minutes later) is correct.

My timezone is set correctly in php.ini. I have NTP sync set up on the servers (I use a separate database server), and the time on both servers is correct. The timezone of the user that sent in this ticket is correct. The default timezone of the system is correct. I'm at a loss on what to try next. Any help would be greatly appreciated. Thank you!

image

Comments

  • The response I got from the devs on this is:
    "we're thinking that it could be that the old server that he moved from was not in the same time zone as the one he moved to, and that he did not convert the data to match the new server. If he is testing on a ticket that was just imported from the old system, the dates would not have been converted, so when he updated the ticket, it used the new configuration. That's assuming he's testing right after updating though... may need a little more info to really tackle the issue"
  • That's not the issue. The migration happened about two weeks back. The two events I highlighted in the image happened only minutes apart in the real world, but the timestamps show more than four hours difference. The ticket itself had been created yesterday.
  • Whats your MySQL database timezone?
  • I checked, and it wasn't set, so I set it to -05:00. The thing is, I had never set this before on the old server. Anyway, let's see if this helps.

    Something I forgot to point out is that the times being displayed in the UI are also four hours behind. Sorry, I kinda got caught up in the timestamp issue. In fact, the UI issue is what kinda started all of this. Here's the thing, though: I had the time displaying correctly after the migration about two weeks ago. This problem started since then.
  • I don't know what happened, but now the system is displaying and saving the correct time. I really don't trust problems that solve themselves, but at this point, I'll take it. Thank you for your help.
  • Very welcome. :)
This discussion has been closed.