Thread

Yes, I will still be available for the at least the next few hours.

thank you derek
we’ve reuploaded all the system-files to be sure that no changes from simon have been forgotten… no changes on the dates 😕

Right, but dates are working fine now for new entries?  The offset you were using was counteracting the date bug that would cause entries to move an hour when editing from the CP.  So now that you aren’t using the offset, they are all showing their “real” dates.

How long have you been using 2.1.3?

we use 2.1.3 since … well … I think December 2010 - or early 2011

well, in the Database, there are even other dates:

for example the entry 10215 has a timestamp of 10:17 in the database, but 12:16 in the CP / Frontend … and it actually was published @ 11:16

Derek, I have a basic question: All timestamps in the database should be GMT, right? And then with the localization settings we have in EE, we get a timestamp back applied to our timezone and observing DST…?

for example the entry 10215 has a timestamp of 10:17 in the database, but 12:16 in the CP / Frontend … and it actually was published @ 11:16

@Stefan - Correct, the database should be GMT, and the publish date would be correct if you published now, but older entries were being artificially pushed an hour by the server offset setting, which explains why now that you aren’t using the offset, those dates are looking incorrect.

@Simon - yes, and those dates were normalized to GMT/UTC in the 2.x update.  Did your original update go smoothly?  I could see in your timezone how if that did not go smoothly that it would have been impacted.  Or if that offset was set at the time of the update, which would have resulted in EE assuming that your server’s natural reported times were 1 hour off.

Yeah, initial update went fine…

But I just recognized, after the standard update from EE 1.7.0 to EE 2.1.3, the timestamps in the database are already GMT+1 so our new installation will never be able to show correct timestamps.

I think the only option is to renormalize our most-important timestamps (like entry_date for channel entries, comment_date for comments, post_date for forum posts and topic_date for forum topics) with a self-made script which simply removes 3600 seconds from the timestamp.

I know there are still other timestamps but we can accept when they leave wrong.

The most important message is, we can see well-formated timestamps for all new entries, means proper GMT-timestamp in the database and timezone applied and DST observed timestamps in the frontend and CP.

Simon, you may even be able to do that with a few simple queries, e.g.:

UPDATE table_name SET time_field = (time_field - 3600) WHERE time_field < timestamp_of_2.x_upgrade

Or the timestamp of when you disabled the server offset setting, more accurately.  Make sense?

Yeah, I just came up to the same query, thank you! 😊

Makes absolutely sense.

So, I like to thank you very much for your support, this was very helpful for us and we’re sorry for the inconvenvience… going to spend some bottles of beer when you come visiting Switzerland 😊

Glad I could, Simon and Stefan, I just happened to see the panic this morning and thought I’d try to help.  Now I have to find an excuse to go to Switzerland. :-D

I’m going to go ahead and close this thread, but if something else comes up don’t hesitate to start a new (or a related) thread.