I have adodb date library installed and it seems to work fine, except when I re-edit a node. Upon opening the edit page, the date field defaults to 1970 from the historical date I'd previously entered and successfully stored. Most of my entries are for the 18th Century, so I run into this bug quite a lot.

type of field: date
type of widget: text
timezone option: site
multiple option: no
required: yes

Comments

karens’s picture

karens commented
Status: Active » Fixed

A new official release has been committed which I think will fix this problem. Reopen if not.

fm’s picture

fm commented
Status: Fixed » Active

No change on this end. The behavior persists.

The fix did not require a database update, did it?

karens’s picture

karens commented

Yes, there is a database update. It's always a good idea to check update.php just to be sure.

fm’s picture

fm commented

updated database; still no change in field behavior.

karens’s picture

karens commented
Status: Active » Fixed

This was really hard to find, but I finally figured it out. There was one place in the code that was trying to apply a timezone adjustment to old dates and that was creating an invalid date, which defaulted back to 1970. Fixed in latest commit on all branches.

fm’s picture

fm commented

The release date, both on the download page and in the file header, still indicates Februray 1st.

karens’s picture

karens commented

You need the nightly snapshot to get the changes. On the project page, choose 'Other releases' and look for the 4.7 nightly snapshot.

fm’s picture

fm commented
Status: Fixed » Active

Ah, thanks. Okay, we're making progress.

Instead of reverting back to 1970, it loses a day. For instance -- If the date is Oct 1 1777, upon opening the edit page the date displays as Sep 30 1777.

Btw, thank you for the work you've already invested in this. It is greatlly appreciated. :)

karens’s picture

karens commented
Status: Active » Fixed

The problem is that there were still a few places where the program was trying to do timezone conversions on dates that should not get them. I hope I have now found and fixed all these problems in latest commit.

fm’s picture

fm commented
Status: Fixed » Active

Same problem persists -- losing a day.

karens’s picture

karens commented

Bah! I'll look into it more. Something somewhere is trying to apply a timezone adjustment -- it could be the server, mysql, php, the date module, or who knows what else...

karens’s picture

karens commented

I can't replicate the problem any more. It's fixed for me. Can you:

1) Check the version and date for the date.module and date.inc files you are using. You must be using the latest cvs snapshot version to have all my recent changes. You should see

// $Id: date.module,v 1.13.2.31 2007/02/15 14:39:01 karens Exp $
//$Id: date.inc,v 1.9.2.21 2007/02/14 21:11:51 karens Exp $

2) If you have the right code, also be sure you visit update.php and run any updates you find there.

3) If you have done the above and still have problems, tell me the following:

- The type of field (date or datestamp).
- The type of widget (selector, jscalendar, or text).
- The timezone option being used, the actual timezone that represents (i.e. 'site', 'US/Eastern').
- Whether you are using the 'multiple' option.
- Whether you are using the 'required' option.
- Whether you are using the 'to date' option and if it is set to required or optional.
- The timezone you have set up for your own user record.
- The timezone you have set up as the site timezone.
- The timezone your MYSQL server is running in.

fm’s picture

fm commented

1) Yes and yes. I've got them both.

2) Done. (I am not given a choice of updates, it runs everything in queue.)

3) As follows ...

- The type of field: date
- The type of widget: text
- The timezone option being used, the actual timezone that represents: site (alt. "no timezone conversion," same result)
- Whether you are using the 'multiple' option: no
- Whether you are using the 'required' option: no (though I should reset that to "yes")
- Whether you are using the 'to date' option and if it is set to required or optional: never
- The timezone you have set up for your own user record: -0500
- The timezone you have set up as the site timezone: -0500
- The timezone your MYSQL server is running in: PST (-0800)

karens’s picture

karens commented

If you're running MYSQL with a version of 4.13 or higher, the fix I just committed for http://drupal.org/node/120154 may be the thing that was causing this problem. Can you confirm one way or another whether the very latest file (just committed a few minutes ago) fixes your problem?

fm’s picture

fm commented

MySQL version 4.1.20 is running on this server.

for what it's worth, I'm also using PHP 5.1.6

karens’s picture

karens commented
Status: Active » Fixed

Finally! I found the problem. The adodb get_gmdate function was adding in a timezone adjustment, so I had to use a different function to keep the timezone adjustment out of the results.

fm’s picture

fm commented

Yea! It works! Excellent!

Thank you again for your hard work and perseverance!

Anonymous’s picture

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