Calendar and date selector to search archive don't work correctly with user timezone, because this module use system-timezone-sensitive function mktime() and date().

I use Drupal on +0900 (Japan) timezone system, and I also set user timezone to +0900. When I post node with time '2006-07-12 18:00:00 +0900', it stored with unix time 1152694800 in created. This is correct.

But when I search nodes using archive module with date '2006-07-12' in Japanese timezone +0900 (I expect), these parameters are converted into unix time by mktime() function (with +0900 system timezone) and subtract user timezone seconds from converted time.

 $date = mktime(0, 0, 0, $month, $day, $year) - $user->timezone;
 $date_end = mktime(0, 0, 0, $month, $day + 1, $year) - $user->timezone;

This results double-processed (and wrong) unix time 1152597600 (2006-07-11 15:00:00 +0900) and 1152684000 (2006-07-12 15:00:00 +0900). My node '2006-07-12 18:00:00 +0900' is not selected by this query.

To fix this problem, need to use system-timezone-independent function gmmktime() instead here.

date() function has similar problem, use gmdate() instead.

In addition, SQL select condition in archive_page() function is not correct (IMHO).

Attached patch (for CVS version) works for me.

Comments

gábor hojtsy’s picture

Version: x.y.z » 4.7.3

You picked up this issue on the contrib archive module, and it is fixed there. Archive module was removed from core (will not be in 4.8/5.0). Maybe new 4.7.x releases will fix this timezone problem? This is why I keep this patch open for the 4.7.x release process.

seanr’s picture

+1
Seems a fairly common sense fix.

killes@www.drop.org’s picture

I'd like to have somebody test this.

beginner’s picture

Project: Drupal core » Archive
Version: 4.7.3 » master
Component: archive.module » Code
Status: Needs review » Needs work

archive.module no longer part of core.
patch from root as per guidelines. http://drupal.org/patch

gábor hojtsy’s picture

Project: Archive » Drupal core
Version: master » 4.7.3
Component: Code » archive.module
Status: Needs work » Needs review

beginner, it would have helped, if you read the comments on this issue. We are talking about fixing this up in a 4.7.x maintanance release. The contrib archive module has no such problems.

stevenpatz’s picture

I thought that only critical issues would be fixed in 4.7.x and new features would go in cvs?

killes@www.drop.org’s picture

even minor fbugs in 4.,7 will get fixes as long as somebody tests the provided patches...

beginner’s picture

StatusFileSize
new7.65 KB

To make amend for my hasty review earlier, here is the same patch, re-rolled and diffed from ROOT, as per guidelines.

beginner’s picture

Status: Needs review » Needs work

I have never used the archive module before, so I am not sure how to review this patch.

My time settings are set to GMT.
My account settings are set to GMT + 8:00

I am making posts and write the time/date in the title field.
Then, when I try to view the list at ?q=archive/2006/10/6 , the list of nodes have the right date/time with or without the patch, whether the nodes where posted with or without the patch.

I set to patch needs work until someone can give a precise set of instruction before/after the patch, how to reproduce the bug and what to expect.

The patch is fairly big, so what different tests should be carried out?

magico’s picture

* oishi proposed a patch
* Gábor explained that archive.module is not in Drupal 5 but should be fixed for 4.7
* beginner rerolled the provide patch, but does not have enough information to review it

killes, what should be done about this?

killes@www.drop.org’s picture

There should be more reviews and testing :)
Or at leaast confirmation that the fix works for the contrib archive module.

udvranto’s picture

It works correctly for logged in users. But for visitors the $user->timezone is empty and shows incorrect information. The default drupal time zone should be used instead.

pasqualle’s picture

Status: Needs work » Closed (won't fix)

This version is not supported. Reopen or create a new issue if the problem exists in any recent version (version equal or above Drupal 5)