I added a CCK date to my content type, with this configuration:

Basic information
Widget type - Select list

Settings
Default value: Blank
Customize Default Value: not changed
Input format: 10/31/2008 - 23:07:01
Custom input format: empty
Years back and forward: -200:0
Time Increment: 1
Help text: empty

Global settings
Not required
Number of values: 1
To Date: Never
Granularity: Year, Month, Day
Date display: 10/31/2008 - 23:00
Custom display format: empty
Additional Display Settings: not changed
Time zone handling: No time zone conversion

The bug:
When I create a node which contains this field, then always ok. I fill the date field with May 22, 1911 for example. But when I want to edit this node, the value of the "day" field is always decrement by 1, so, on the edit screen the displayed value is May 21 1911. When I save the node, and edit again, the displayed value is May 20 1911, and so on.

Comments

zoltán balogh’s picture

Version: 6.x-2.0-rc4 » 6.x-2.0-rc5
Priority: Normal » Critical

I think it is a critical error, because the date cck field is unusable in this state.
Everytime, when somebody edit a node, which is contain a cck date field, the value of day is changed, and it is independent from the widget type.

karens’s picture

Status: Active » Fixed

I've made a number of recent commits to fix problems with dates that use no timezone handling and I can't reproduce your problem in the latest code, so I believe this is fixed in -dev. The fixes will be in the next release.

zoltán balogh’s picture

I tested the current -dev version, and this is works fine. Thanks.

zoltán balogh’s picture

Status: Fixed » Needs work

Ohh no, the saved value is bad. I set the day to 22 for example, and if I want to save, the saved value is 21. Edit again, the displayed value is 21. Correct. Save again, the saved value is 20. Ooops.

karens’s picture

Status: Needs work » Postponed (maintainer needs more info)

Are you sure you have all the fixes? I just made them yesterday and they don't roll into the tarball right away. It was definitely broken before and is definitely fixed now in the latest code. Unless you got your updated code directly from cvs, you probably didn't have everything.

karens’s picture

Status: Postponed (maintainer needs more info) » Fixed

No response in a month, so closing.

Status: Fixed » Closed (fixed)

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

bgogoi’s picture

hello!

on date 6.x-2.2 -- I have the same problem. http://drupal.org/node/491822

no solution as of now ..