When you look at the time of the post is that in the Admin, Manage, Posts screen? Or are you talking about the time used when it displays the post on your blog–in that case your Theme might be the culprit.
Both… the times set in Admin/Manage and on the blog itself are both in UTC… when writing new posts, the time defaults to the current UTC time. When I try and change the time zone under options/general, it doesn’t seem to do anything, as the field won’t retain any information and nothing actually gets entered (and there’s not even a field on any table for it) in the MySQL database.
What might be helpful is if I could find the location of the process referred to as the_time() in wordpress, then I could manually set the offset in the formula… but I’m having trouble finding that.
Really, I wish there was an option just to have the time default to current time at the server rather than try to go by GMT. I’m not even sure where it is getting the time from.
Dumb question, but do you check the “Edit timestamp” checkbox before updating your settings?
I don’t see a checkbox like that on the options menu… there IS one under the advanced editing options during writing a post, but I wish there was another way other than cranking back the time by 5 hours on every post.
We’ve got exactly the same problem as you ! When filling a value in the UTC time offset in the options / general form, after submitting it the value disapear and everything works as if no change was made (all posts times appears in UTC)
The same WordPress version installed on a Windows with easy-php works fine : when the options form is submitted the value remains and it is actually used by WordPress…
As someone suggest here there is still the possibility to change the time when creating the post, or change the output in the theme, but it’s not very convenient… Furthermore, here in France we have a daylight saving in place, so in summer it’s UTC +2h and in winter +1h – could WordPress include a daylight saving handling ?
WP will not include a daylight saving option due to the lack of uniformity in and handling of DST.
OK, thanks for the answer. It won’t be so difficult to change twice a year the UTC offset parameter… if it is possible. Any suggestion for us to be able to update the parameter ? Could this be caused by a PHP setting ? A platform specific configuration ?
I can’t figure out why this doesn’t work, and it is very soon going to become a make-or-break issue, as I would rather use wordpress for a company website we are authoring now, but if we cannot automatically display posts in local time, I may be forced to find different blog software, because the people who will be making submissions are semi-computer-illiterate and cannot very well be taught to adjust the date on every submission they make.
I’ve dug through the Database and can’t even find the place where the offset would be stored for me to change it manually… has anyone who has this working on mysql 4 got an idea of where to find the database entry for this offset?
Browse the “wp-options” table, locate (around) row 63, gmt_offset. Change the listed number to the actual offset. See if that helps….
Thanks vkaryl, that helped me find the problem. The problem was, apparently, that the setup did not create the entry for gmt_offset in the wp_options table, and the administration tool doesn’t create it if it is missing.
So the solution, for others who may have the same problem as me, such as piR, is that you have to insert a new record manually on the database server. We use a php mysql admin package to do it so it was pretty straightforward. The fields should go something like:
option_id: whatever the highest item in your table is, +1 (must be unique)
blog_id: same as all the other records in the table, probably 0 unless you have more than one blog running in this database
option_can_overwrite: Y
option_type: 1
option_value: (your offset here, but whatever number you put here you can then successfully change it later in the administration)
option_width: 20
option_height: 8
description: (blank)
admin_level: 1
autoload: Y
Entering a new record with the above information fixed my blog.
Thanks for providing the answer that worked for you. That should help the next poor guy who comes along with the problem!
Happy holidays!
I had the same issue. Is there a bug report filed for this? What other info is missing from the options table? On earlier versions, there are 79 records in the options table, but with 1.5.2, there are only 74. So, it seems we are missing the gmt_offset and 4 others.
It works perfectly right, many thanks !
One more question : are the options in this table listed somewhere so I can check they’re all there ?
