[support] support at drupal.org

[Cary Gordon]

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 at 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/ ]