I'm not aware of any time issues with the site, everything appears to be normal.
Post time stamps are immutable. The only server-side calculations involve adjusting the displayed time to account for the time zone selected in a user's account settings, but the time stamp itself remains the same. Relative time stamps ("33 minutes ago") are calculated entirely inside the browser, fully dependent on the time it reports.
The most interesting thing about Private Mode is the fact it typically runs with browser plugins disabled. I don't know what was causing your problem, but I suspect a browser plugin or privacy setting was somehow at fault (see below).
The fact that it's fine on the server side does not mean there isn't an issue with the website. The client side code may still have a bug in calculating the offset.
This issue has occured for me several times over the last few days, and
only on GTPlanet. All other websites are correctly showing anything based on my browser time.
What I find odd, is that it initially shows the time correctly, and then after a second or so, switches to the wrong time. This suggests that at least initially, the calculation is able to correctly get the time from my browser. Only after that, something gets messed up and it breaks. Refreshing the page does not fix the issue, but again flashes the correct time, and then switches to the wrong time again (with the same offset). Same for closing the tab and reopening. After a few hours, the problem seems to fix itself, only to return again a few more hours later.
I don't run any browser plugins or have any special privacy settings.
For completeness sake, I
am also running Firefox mobile.
Firefox has a privacy "feature" which will
intentionally misreport the time and break the relative time stamps here. You can check to see if you have that enabled.
The Firefox resist fingerprinting feature should only report different timezones to my understanding. There is no timezone with a 33 minute offset (or any of the other offsets I've seen over the last few days), so that wouldn't explain it. Also, the calculation of relative timestamps should be respecting the reported timezone, so the relative time should still be correct.