3

I am using a sitemaps plugin which in very complex ways sets the timezone of <lastmod> (i.e. last modified time) for posts to GMT.

Temporarily, until the plugin developer fixes it, I need to enforce a custom timezone on the plugin. The simple and straightforward way that I've found is to add something like date_default_timezone_set( 'America/New_York'); right after the first <?php in the file responsible for outputting the sitemaps.

It works, and it doesn't seem to affect timestamps displayed on the rest of the site. So, can I go with this? or is there a better solution?

1
+50

http://codex.wordpress.org/Function_Reference/get_gmt_from_date

Replace all instances of get_the_date or the_date with echo get_gmt_from_date(get_the_date('Y-m-d H:i:s')). That's not a quick fix, it's a way to fix your sitemaps.

EDIT:

WordPress SEO runs it's raw dates from MySQL through a WP function called mysql2date, which in turn calls date_i18n. date_i18n happens to have a handy filter which you can tie into to change the date:

<?php
add_filter('date_i18n', 'wpse57195_filter_date', 10, 4);
/**
 * Changes the date on WordPress SEO's sitemaps
 *
 * @return string The Date
 */
function wpse57195_filter_date($date, $format, $timestamp, $gmt)
{
    // if this isn't a sitemap page, bail
    if(!get_query_var('sitemap'))
        return $date;

    // W3C Time format with -05:00 for central time
    // NOTE: this doesn't account for daylight saving time
    $f = 'Y-m-d\TH:i:s-05:00';
    return $gmt ? gmdate($f, $timestamp) : date($f, $timestamp);
}

In the hooked function, you can check for the sitemap query variable and change the time as you need. To keep with the sitemap spec, you have to use the W3C date format which includes a +/- field for timezone. -05:00 is the number for central, daylight savings time. You can wrap the above up in a plugin and activate it until the sitemap can be fixed.

  • Thanks for the suggestion, but the plugin's code is more complex than that. Please take a look: gist.github.com/201ec6b0c50317040837 — for instance, $date = date( 'c', strtotime( $date ) ); is later used like this: $this->sitemap .= '<lastmod>' . htmlspecialchars( $date ) . '</lastmod>' . "\n"; — And that's not all. Down the code, there's more. – its_me Jul 6 '12 at 16:03
  • Ah, in that case: you don't need to do anything: gist.github.com/201ec6b0c50317040837#L321 Yoast uses the GMT date. – chrisguitarguy Jul 6 '12 at 16:53
  • I don't want GMT. That's the problem. I need to set it to a different time zone (e.g. America/New_York). – its_me Jul 6 '12 at 17:06
  • 1
    Actually, I can't use the function. Reason: WP's date-time function is broken (by design, they say), and I had to fix that manually, as you can see here. Sorry about the growing complexity. Any changes I can make directly in the file would be fine. Thanks for your time. :) – its_me Jul 7 '12 at 1:43
  • 2
    Why do you want to change the lastmod time to not be GMT? Everything expects that value to be GMT, if you change it to something else, then your sitemap will be incorrect. These things are standards for a reason. – Otto Jul 7 '12 at 22:16
1

Currently, the built-in function current_time() expects function date_default_timezone_set() is never used.

Inspecting the code of current_time() confirmed this, because that function formats the result using PHP built-in date() function (that is affected by timezone); in fact seems Wordpress always resets the timezone to UTC (an echo date_default_timezone_get() placed at top and at bottom of wp-config.php in a clean WordPress setup will prove this).

See https://core.trac.wordpress.org/ticket/38940

0

No. (well, you could immediately change it back after you're done, but that's error prone.)

Also, whatever you do don't override date_default_timezone_set() in your wp-config.php; wp-settings.php sets this to UTC and you mustn't change it.

Setting to Europe/London, for example (which is one hour ahead of GMT in summer), will make GMT one hour ahead of what it ought to be - you can verify via /wp-admin/options-general.php

Essentially, this means values of the system timezone /etc/timezone and PHP's date.timezone ini value are ignored by WordPress.

IMHO, there ought to be some sort of warning in WordPress core if it's set to a value other than UTC, but there isn't, so beware.

Related WPSE question - Related blog

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.