I'm using CCK to create a custom content type ("Date") with field_date (a text field with strotime validation). field_date has a custom input and display format: Y. So it only takes a four-digit year parameter. That's because I'm making a timeline that spans from 1304 to 2004, and anything more granular than years is too much to worry about on that scale. (The granularity is also set to Years.) No time zone conversion. There is an optional To: date and the field is required.
When I type a date into field_date and submit the node, the date gets processed and comes out a year earlier than intended. For example, if I write "2008" into field_date and submit the node, the displayed result is "2007."
Thoughts? Help? Thanks. PHP5.2, D5.7, MySQL. The site has basically only a few core modules (Menu, Taxonomy), Date, and the Timeline module.
| Comment | File | Size | Author |
|---|---|---|---|
| #24 | date.install.patch | 924 bytes | bcn |
| #12 | screenshot.jpg | 224.09 KB | icecreamyou |
| #12 | datesettings.jpg | 141.93 KB | icecreamyou |
Comments
Comment #1
icecreamyou commentedBy the way, this happens every time the node gets submitted, including if it gets edited. So for example, if the node was created with 2008 in field_date and submitted, it would say 2007; if it was then edited and re-submitted (but the date wasn't changed) it would say 2006; and so on. This is something of a problem because I have a user that's going to be repeatedly editing each node.
Comment #2
icecreamyou commentedSpecifically, I discovered that the date gets assigned to 30 Nov [Inputted Year - 1] 00:00:00 GMT which is quite strange.
Comment #3
icecreamyou commentedAfter more exploration, I think this occurs in date_api.module in the function date_diff().
Lines 732-736:
That's the only place in date_api.module or date.module that I can find where 1 might possibly be subtracted from the year.
Comment #4
karens commentedThat's not the problem, date_diff() is not used on the node submit. Update to the latest dev version of date and see if you still have problems.
Comment #5
icecreamyou commentedTested the latest 2.x dev. This is so weird.
When a node is first created, no matter what year is put in, the result is the year 1970. When it's updated, the year increments by one - the opposite behavior from before.
I am very confused.
Comment #6
icecreamyou commentedUpdating to dev, even though it really applies to all 2.x releases.
Comment #7
karens commentedI have no problem and can't replicate this. I fixed a similar problem recently and it works fine for me now. Please paste an export of the date field you created so I can see how you set it up.
Comment #8
icecreamyou commentedAll I get when I go to export the field is this message:
...but I think I have something significantly wrong with my Date installation. Maybe an extraneous file from an earlier version is still there messing things up. I'll retry everything and see how it goes.
Comment #9
icecreamyou commentedOkay, I just removed the date module folder and put in a fresh copy of it from d.o - I have the same problem. I didn't want to uninstall because I wasn't sure if the data from my nodes would be erased.
Since I updated from 2.0rc to 2.x-dev though, it's gone back to 1.x behavior (i.e. no dates allowed before 1970). That makes me think there's a larger problem here.
Comment #10
karens commentedWhat version of everything are you using? You should not be seeing that anywhere. Are you trying to use the HEAD version of CCK or Date?
Comment #11
icecreamyou commentedYou told me to try 2.x-dev, so I did. I'm using this one.
Comment #12
icecreamyou commentedAttached is a screenshot of my modules page.
EDIT: I tried this with and without the Date Popup module enabled. Right now it's disabled. Also, I've added a screenshot of the date field's settings page.
Comment #13
karens commentedTurn on Content Copy so you can create an export of your field.
Comment #14
icecreamyou commentedNo one ever told me it was *Content Copy* and not *Date Copy* that had to be enabled (by the way, I had Date Copy enabled but I disabled it before taking that shot). :D
Here's the export.
See also my last post--I added a screenshot of the date field's settings page.
Comment #15
icecreamyou commentedThis is really annoying.
I use date on another of my websites, and I'm using the same version of the module on that site as the one I'm having the problem with; but on my other site, it's working just fine.
...I'll work on trying to figure out what's different. Thanks for any help so far, and of course I'm still interested in any comments, questions, or solutions you might have.
Comment #16
karens commentedThe granularity array looks funny -- that zero doesn't belong in there. Try pulling up the field edit screen, double-check all the settings, and re-save it (even if the settings look OK). Then try another export and see if the granularity loses that zero. If so, try creating your date again.
Comment #17
icecreamyou commentedI tried what you said. I also tried changing some settings, saving, then changing them back. The zero is still there.
Then I removed the zero manually from the text and imported the result into a new field for the Page content type. The same thing was happening, so I exported the field from the Page content type - and the zero had reappeared.
Will I lose any data from existing nodes if I uninstall (and then reinstall) Date? Will that even help anything?
Comment #18
karens commentedIt sounds like there is a bug in the program putting that zero in there, so I need to figure out what it is.
Comment #19
icecreamyou commentedWell, I haven't been able to find any differences between my sites that would affect Date.
I don't know much PHP, but let me know if there's anything more I can do.
Comment #20
icecreamyou commentedA possible clue: I upgraded to the latest dev version just now and ran update.php, which gave these errors:
Comment #21
okeedoak commentedI have the same subtract-a-year problem here. And I just received the same errors you did in #20. I went from the rc to the latest dev, then ran update.php.
Comment #22
okeedoak commentedHere's an export:
Comment #23
karens commented#20 was the clue I needed. That is a typo that used the file naming convention used in CCK D6 instead of the one used in CCK D5. Fix committed.
Thanks, and sorry!
Comment #24
bcn commentedHi Karen,
I think the fix you made for this also has a small typo...
The 5.x version of cck doesn't have an 'includes' sub-directory.
Comment #25
karens commentedThat's what happens when I try to do too many different things at once :)
Thanks, fix committed.
Comment #26
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.