Posted 7 years ago #
Hey all, I'm having a confusing problem here... Currently I am UTC -5, but when I put that in under the options panel and update, it refreshes the panel as having that field blank, and any posts I make after that are still listed at UTC time. Has anyone else run into this, or know how to fix it?
Edit: You know, I could have *sworn* I was posting this in the admin forum >.<
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.
Posted 7 years ago #
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?
Posted 7 years ago #
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.
Posted 7 years ago #
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.
Posted 7 years ago #
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 ?
Posted 7 years ago #
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?
Posted 7 years ago #
Browse the "wp-options" table, locate (around) row 63, gmt_offset. Change the listed number to the actual offset. See if that helps....
Posted 7 years ago #
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.
Posted 7 years ago #
Thanks for providing the answer that worked for you. That should help the next poor guy who comes along with the problem!
Happy holidays!
Posted 7 years ago #
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.
Posted 7 years ago #
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 ?
This topic has been closed to new replies.
