I suggest that you take a look at a Drupal 7 date field, which might be called field_data_field_date/field_revision_field_date. This is a typical row from the data table:
'node', 'event', '0', '272', '6566', 'und', '0', '2012-11-07 20:00:00', '2012-11-07 21:00:00', null
Since this was caused by a (presumably) one-time import, their is little to be gained but spending time analyzing it. The goal is to solve the problem.
Yes, it would be a very good idea to back everything up before screwing with the data.
On Aug 17, 2013, at 5:11 PM, Earnie Boyd earnie@users.sourceforge.net wrote:
On Sat, Aug 17, 2013 at 5:33 PM, Cary Gordon wrote:
Tashi Delek,
I guess the first question is, what is "the date import script"?
Without knowing anything about the site, I can tell you that I would not deal with figuring this out. if all the times are off by exactly two hours, I would dump the data table into a spreadsheet and correct the times. you need to do this in both the data table and the revision table
In Drupal 7, dates are stored like 2013-09-20 16:00:00, so obviously, any correction will need to deal with date boundaries.
Dates are usually stored as unix timestamps which are timezone neutral. The display of time is what controls what is seen based in a timezone. Is the timezone for the server and application correct? Don't go fooling about with the data before you know what the cause is. And when you do fool with data, do a backup of the database first.
There are lots of tools for manipulating the database. I use NaviCat.
Never heard of that.
-- Earnie
-- https://sites.google.com/site/earnieboyd
[ Drupal support list | http://lists.drupal.org/ ]