After successfully performing a migration of date fields from D6 to D7 with the CVS version of date, dates display one day behind. i.e. 8/13/2010 in the db displays as 8/12/2010 on output. This only seems to occur with migrated date fields. If I then make a new node using the same, migrated content type, the dates display correctly.

Comments

jon betts’s picture

jon betts commented
Priority: Normal » Major

To clarify, a date field that contains the following value in mysql, 1999-09-14 00:00:00 shows the following value in the form field as well as on output, 9/13/1999. Changing the priority to major as a date infers accuracy.

mecano’s picture

mecano commented

I have this on two 6.19 servers, setting "User-configurable time zones" to off seemed to solve the issue on one but not on the second, only difference I spotted for now is second has date.timezone specified in php.ini.

jon betts’s picture

jon betts commented

@mecano, thanks. I had already checked the User-configurable time zones and set it to off and there doesn't seem to be anything set in the php.ini file. I've tried converting the site three different times on two remote and one local server and have had the same problem. I'm converting a 6.20 site. The dates are fine in the db so I don't know if there is anything programmatic that can be done to correct them as they are already "correct". Maybe there is a rogue timezone setting in the db that isn't part of the UI but is effecting the output. Editing the content type manually works, but I've got thousands of nodes to edit.

arlinsandbulte’s picture

arlinsandbulte commented
Version: 7.x-1.x-dev » 7.x-2.x-dev

Date 7.x-1.x is unsupported.
This issue should be verified in the latest version of Date (7.x-2.x-dev) and re-opened if still valid.

Thanks

karens’s picture

karens commented
Status: Active » Postponed (maintainer needs more info)
jon betts’s picture

jon betts commented

I ended up reentering the nodes by hand. Still can't sleep on my right side. I may be integrating another site into D7 which will require the date field in the next few weeks. At this time I'm using Date (7.x-2.x-dev) branch so I'll let you know if this is still and issue.

jelo’s picture

jelo commented

This issue seems related: http://drupal.org/node/1017866

The problem in D6 seems unresolved. As Jason describes it: "The times are stored into the database assuming no timezone handling, but are retrieved assuming that a timezone offset needs to be applied.". To get your migration done, you might be able to change the granularity of the field to hours, set it to "no time zone conversion" or "sites time zone" and then migrate. With granularity of hours, you can specifically say that you do not want conversion, which otherwise gets implicitly assumed as required when you use a granularity of day/months/year.

arlinsandbulte’s picture

arlinsandbulte commented
Status: Postponed (maintainer needs more info) » Fixed

Related issue #1017866: Timezone offset incorrectly handles large granularities was fixed.
I am going to assume that fixes this issue too.

karens’s picture

karens commented

I have never been able to replicate this issue. If it is 'right in the database' the migration is fine. If it was displaying wrong in D6, it is a D6 issue.

Status: Fixed » Closed (fixed)

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