I noticed this issue when working with some event posting in a fresh Drupal 6 installation, and I noticed that the event post date was using GMT, which is NOT the sitewide timezone nor is it the user's timezone.

However, I posted a test story and noticed the same issue.

It appears to be using GMT as the time that anything is published. I have tried changing both the site timezone and my own user profile timezone to Canada/Central and etc/GMT -6, but it does not appear to take effect.

Site Info:
Database updates Up to date
Drupal core update status Up to date
File system Writable (public download method)
GD library bundled (2.0.34 compatible)
Module and theme update status Up to date
MySQL database 5.0.24a
MySQL database for event module 5.0.24a
PHP 5.2.3
PHP memory limit 90M
PHP register globals Disabled
Unicode library PHP Mbstring Extension
Update notifications Enabled
Web server Apache/1.3.37 (Unix) mod_throttle/3.1.2 DAV/1.0.3 mod_fastcgi/2.4.2 mod_gzip/1.3.26.1a PHP/4.4.8 mod_ssl/2.8.22 OpenSSL/0.9.7e

I am attaching a screenshot that shows the discrepancy.

Comments

cjeanson’s picture

Version: 6.0 » 6.1

Still an issue in 6.1.

I can look at the frontpage of any of my Drupal sites and my account timezone, as well as sitewide timezone have no effect on the time that anything is published. It is using GMT.

Any ideas?

miahawk’s picture

I'm also testing 6.1 and publish date/time is GMT for comments as well, although I have the site default time zone set to US/Pacific.

wretched sinner - saved by grace’s picture

Title: Timezones not applying in story publication » Timezone for Node publication is stored as GMT regardless of the Site Timezone.
Priority: Normal » Critical

I also have this issue. It seems to cause a flow on effect in multiple other projects.

For an example, go to http://WhenTheTongueIsDone.net/ and see the test posts that have been entered. The Site timezone is set to Pacific/Auckland (GMT +12), but when I make posts, the timezone is recorded as being GMT, not Pacific/Auckland which it should.

Please let me know if there is anything else I can add to this.

wretched sinner - saved by grace’s picture

Version: 6.1 » 6.2

Still an issue in 6.2

Anonymous’s picture

Priority: Critical » Minor
Status: Active » Postponed (maintainer needs more info)

Can't reproduce in 6.2.

In node.module, the creation/updated/etc timestamps are all created by a call to time(). time() is defined as the number of seconds since the epoch, 1/1/1970 GMT.

The theme itself, is where the date is rendered into what it should be, via format_date(). http://api.drupal.org/api/function/format_date/6
According to the documentation, if the timezone is omitted, then the set timezone is used.

Looking at the calendar.png attachment, it appears you are not using a standard theme. Garland does this properly, in template.php, on lines 78 and lines 83. The culprit is whatever theme you are using, and not the node system.

Dropping the priority down to minor, as this needs to be addressed by whatever theme maintainer.

cjeanson’s picture

Sorry, I am using 6.2 stock with the fluid theme (Garland I believe) and this is still an issue. This is actually an issue on every Drupal site I have ever worked on.

I will go and install a brand new fresh copy of Drupal and try to reproduce.

cjeanson’s picture

Brand new install shows no problems, so I cannot reproduce. However, a site that was installed as Drupal 6.0 (and is now 6.2) has an issue with its timezone setting.

With a "central" default timezone, it displays the current time as GMT. (In the date/time admin menu) which is different from the fresh install that I have just initiated.

Here is my question:

How come my default time zones in my 6.0 upgrade are listed by location, and the new install is listed by GMT setting?

i.e. old system lists: Canada/Central and etc/GMT-5
i.e. new system: Wednesday, April 16, 2008 - 10:32 -0500

wretched sinner - saved by grace’s picture

Status: Active » Postponed (maintainer needs more info)

I have just installed a fresh copy of Drupal 6.2, as downloaded from drupal.org less that 15 minutes ago. The site can be viewed at www.whenthetongueisdone.com. The first thing I did was to post the story on the front page, and then I changed the user registration requirements (for security) and also the date/time strings to show the Timezone. This post is saved as being posted as GMT, when the site timezone is set to GMT +12, which is my local timezone (but not the server timezone which is GMT -5).

If anyone wants the Admin login, let me know and I can send you the details, or create a user account and I can approve full access to you for testing.

Let me know if any further information is required.

wretched sinner - saved by grace’s picture

Priority: Minor » Normal
Status: Postponed (maintainer needs more info) » Active
Freso’s picture

Status: Postponed (maintainer needs more info) » Active

What is the behaviour with Drupal 6 from CVS? And what is the server configuration (does the server machine(s) store the time as "local" or "UTC", what is the server machine(s)'(s) timezone set to, do they run NTP or some other time-keeping application, etc.)? Please be as verbose as possible.

wretched sinner - saved by grace’s picture

The server is running on the Media Temple Grid Service, so I don't have control over large parts of the system. As far as I am aware, the time is stored on the server in UTC, but I am not 100% certain. The server timezone is set to PST (GMT -5), and I assume that they are running NTP.

The configuration that is running this instance of Drupal can be found at http://WhenTheTongueIsDone.net/phpinfo.php. It is worth noting that i get the same issue with PHP 5.2.5 on the same server, and also on Mac OS X 10.5.2 running MAMP 1.7 (Apache 2.0.59 & PHP 5.2.5).

Freso’s picture

Title: Timezone for Node publication is stored as GMT regardless of the Site Timezone. » Sitewide timezone isn't being used
Version: 6.2 » 7.x-dev

Okay, with some testing at destined's test site (thank you for that!), I've deduced that the problem is in the site-wide timezone not being utilised for a) anonymous users, and b) when the per-user timezone is disabled. I haven't dug into the code to see where this happens though, but it's definitely happening. (Oh, with the per-user timezone enabled, the times correctly adjust to the user timezone, even if the time still says "(date, time) GMT" - which is a (lesser) bug all on its own.)

Moving to HEAD for fixing and subsequent backporting (if it does indeed still exist in HEAD).

wretched sinner - saved by grace’s picture

Just tested the site with the latest 6.x-dev (16-Apr-08) and 7.x-dev (17-Apr-08), and the problem seems to still exist.

The site is currently running 7.x now, in case you want further testing with 7.x, or if not required, let me know and I will take the site down.

Freso’s picture

Status: Active » Fixed

And I hadn't noticed the "pm" in the time (I'm used to 24-hour clocks and the "pm" was in lowercase and separated from the rest of the time with a space... :/), so it would appear that the timezone was indeed being used! (9pm+1200 == 9am+0000) So the issue is that "GMT" was being used instead of "GMT+1200" or "NZST" - I do believe, however, that Drupal has nothing to do with this. Drupal just gives a date/time value and a formatting string (e.g. D, d M y, g:i a T) to PHP's date(), so this really sounds more like a bug with PHP('s configuration) than with Drupal. Also, changing the "T" in the time formatting string to an "O" correctly gives "+0200" and "+1200" appropriate, which clearly shows that Drupal is using the proper, per-user or sitewide, timezone settings.

Marking fixed. Feel free to re-open if you disagree with my above reasoning. (Btw, awesome job with the test site, incl. updating it to D7. :))

Freso’s picture

Status: Fixed » Closed (won't fix)

Marking "won't fix" as that's apparently also for the issues we can't fix (ie., is outside of "our" realm). Thank you, killes!

damien tournoud’s picture

Status: Closed (won't fix) » Active

It looks like we should dig into this problem a little deeper. From what I understand in @Fresco#12, that issue may be related to the caching system. Caching is on by default on Drupal 6, and changing the timezone of a website *may not* change the date of already cached pages (especially of anonymous users).

Can someone try to clear the cache to see if it solves that issue?

Freso’s picture

Status: Active » Closed (won't fix)

@Damien:

  1. It's Freso, not -sco. Thank you.
  2. Please read (and understand) my comment #14. Everything I said in #12 is cancelled out by #14. Closing issue again.
damien tournoud’s picture

Status: Closed (won't fix) » Active

@Freso, sorry for writing your name wrong.

The original issue dates back to mid-February, and was not related to the special case of GMT+1200. There is no evidence that the issue is not there anymore. So reopening, again, for further digging.

Freso’s picture

Status: Active » Closed (won't fix)

@Damien: However you cut and slice it, we've figured out than in Drupal 6.2, Drupal 6.x (CVS), and Drupal 7/HEAD, the time is correctly "translated" between timezones. Please don't re-open this issue anymore, unless you can actually re-produce the (originally) reported issue. If you can reproduce it, then please answer the questions I asked in comment #10.

cjeanson’s picture

StatusFileSize
new178.52 KB
new74.75 KB

So here is the stupid question. For all of my sites that are displaying the wrong time which are upgraded from 6.0, what do I do? Same PHP setup between the sites running fresh 6.2 and the upgraded 6.0, and the problem still exists with the upgraded version.

I can log in to the upgraded site, check the date/time section and see evidence that the wrong time is being understood. I can change the timezone to ANYTHING and the time doesn't change in the date/time area. Obviously, something is askew.

First image is shown at 11:06am, and it is obviously not using my offset, instead it is using GMT.

Second image shows site info. Keep in mind that the site is using an older version of event module, which is why there is a notification there. Currently some issues with event which are delaying the latest version of module upload.

Freso’s picture

As said, the trouble might lie with the server's clock. It was also put to my attention that you're talking about the event module - this might also have a role in it. Check whether Event calls format_date() anywhere, and make sure it's calling it properly if it does.

cjeanson’s picture

Sorry, I thought I clarified later that this also applied to story publications as well.

Keep in mind that the server that BOTH installations are residing on are the same. The one (6.2 fresh) that works, and the one (6.0 upgraded to 6.1 and then 6.2) that doesn't.

Bundus’s picture

StatusFileSize
new39.42 KB
new39.24 KB
new38.64 KB
new40.18 KB

I actually have this exact issue as well. I went from 6.0 to 6.1 to 6.2 and all my times are off. I can change the site wide timezone to anything and it doesnt change the displayed date anywhere. All the attached pictures were taking around 8:00pm on Sunday April 27, 2008

Freso’s picture

Status: Closed (won't fix) » Postponed (maintainer needs more info)

@Bundus: Please see my comment #10. Also, try to change the timezone to ±XXXX instead of using a named timezone. (I can't recall ever having had a Drupal install which used named timezones though... is this really vanilla core?)

Bundus’s picture

#24 you were absolutely correct. I had a module that for some reason felt the need to mess with the timezones. Module disabled, everything is A+ now. Thanks.

For those curious, the Event module causes all these issues.

Freso’s picture

Project: Drupal core » Event
Version: 7.x-dev » 6.x-2.x-dev
Component: node system » Code
Status: Postponed (maintainer needs more info) » Active

I think this was the conclusion when I talked with someone else about it on IRC (catch?), so I'm going to move the issue there, instead of having it clobber the core queue.

marcelovborro’s picture

Unfortunately the event module is a mess. There are dozen of bugs and there're almost no answers to the bug reports. I have some sites that depends heavily on the event module but I Think I'll have to look for alternatives.

gerhard killesreiter’s picture

@cjeanson I'd like to figure out what is wrong with your setup. Can you contact me in IRC?

@marcelovborro: Maybe check out date.module

gerhard killesreiter’s picture

Status: Active » Closed (duplicate)

Some investigation shows that on cjeanson's Drupal install the event_timezones table was faulty. This is probably related to this bug:

http://drupal.org/node/227501

Marking duplicate