I tracked this down to the following code in date_adj_zone($timestamp)

  // No timezone adjustment for very old dates.
  if ($timestamp < 86400) {
    return $timestamp;
  }

I'm not sure why this was originally done, but the only place date_adj_zone() is called is date_gmgetdate(), and at least on my system getdate() adjusts old dates by timezone, too.

The patch removes the above code. Whether this is the right fix or not, this is corrupting my date data! :-(

CommentFileSizeAuthor
#7 olddate2.patch753 bytesschuyler1d
olddate.patch454 bytesschuyler1d

Comments

ehowland’s picture

ehowland commented

Just to say that in working with birthdays I found that people were getting two days younger from one edit to the next. Looking at the data in the database they were only one day younger. So it seems that they got one day younger going into the database and one day younger coming back out.

This patch fixed my problem.

ehowland’s picture

ehowland commented

OOPS should have said getting two days older as the birthdays move earlier two days. I also should have said that this is using CCK date type with the date module, and no time zone conversion, GMT. This showed up in two calls to http://localhost/node/4/edit

ehowland’s picture

ehowland commented
schuyler1d’s picture

schuyler1d commented
Status: Active » Needs review

It seems the burden is on the justification for the old code being there at all.

add1sun’s picture

add1sun commented

FYI, here is the original issue where the code was added: http://drupal.org/node/114088

AjK’s picture

AjK commented
Status: Needs review » Reviewed & tested by the community

Applied and tested.

schuyler1d’s picture

schuyler1d commented
StatusFileSize
new olddate2.patch753 bytes

I don't have adodb--I imagine because of the current code no one who does is paying attention to this bug, but assuming add1sun's bug reference was specific to adodb, this patch should work for everyone.

Any selfless people with adodb environments?

AjK’s picture

AjK commented
Status: Reviewed & tested by the community » Needs review

Nice one, switched a rtbc back to review.

jwbuzz’s picture

jwbuzz commented

Using 1.6 of the date module, I was seeing the same behavior where every time a content type with a date field was edited or submitted, it decremented any pre-January 1, 1970 dates by 1 day. I applied this patch and tested it and it's working correctly.

karens’s picture

karens commented

If you're able to, try this on the 5.2 version of the Date module (which is now in HEAD). Don't try that on a production site, since it makes some changes to the settings stored in the database, try it on a test bed. The formatting, display, form handling, and method of computing dates and everything else is changed in that version (and it has lots of features that have been requested for a long time).

The new version does not use adodb or any other external files. It uses the PHP5 date handling, where available, and has some wrapper functions to make the PHP5 date functions work in PHP4. The code in this patch will not work and should not be needed in the new version.

karens’s picture

karens commented
Status: Needs review » Fixed

This should be fixed in the 5.2 version, which is not quite ready for an official release. You can see that release if you look for 'other releases' on the project page. Try it in a test environment, or be prepared to update it as bugs are found and fixed.

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

bgogoi’s picture

bgogoi commented

I am facing the same problem in d6 version. anyone got a solution for this??