I am using the latest DEV of the Date Module but am having an issue with setting the times. Basically, they get 4 hours added to what I set them as. If I enter 7:00PM it displays as 11:00PM, even when I preview it. I know it probably is some timezone setting somewhere, so I was just wondering what settings I should check to try and fix this?

Comments

sprugman’s picture

sprugman commented

I'm having the same issue (on 6.x.2.x-dev), except mine is subtracting three hours. (I'm in CA, but the site is set to NYC.)

Oh -- also, the server's running php 4 IIRC.

karens’s picture

karens commented
Status: Active » Postponed (maintainer needs more info)

Are you using PHP 5.2 or PHP4? If you're using PHP4, see if the very latest code with the fix I just committed for http://drupal.org/node/269834 takes care of the problem.

sprugman’s picture

sprugman commented

Hi,

Just installed the July 4th dev version. I'm still having issues:

- create a new node w/ a date field
- enter july 5, 4pm as start time, leave end time blank
- save
- node page displays 5pm
- go back in to edit mode
- time field displays 8pm
- save
- node page displays 9pm
- edit > displays midnight on july 6
- etc.

Running PHP Version 4.4.4

TIA

karens’s picture

karens commented

If you're using the tarball date 7/4/2008, you don't have today's commits and you'll need to try again tomorrow when they get into the tarball. If you're using the very latest version from cvs, you have today's commits and that means the problem is still there. So I need to know which 'latest version' you have.

sprugman’s picture

sprugman commented

ah. no, I'm using the tarball, not cvs. I'll check again tomorrow....

compuguru’s picture

compuguru commented
Status: Postponed (maintainer needs more info) » Active

I'm running PHP 4.4.7. I too downloaded the tarball for today, and that didn't fix it. Will wait until tomorrow...

compuguru’s picture

compuguru commented

Just updated to the 07/06 tarball, no luck. I did notice a bit of a strange behavior. To try debugging this, I selected different timezone conversions for my Date Field. I also double checked that the Site Timezone was set to Chicago, and Chicago was also in my profile. I then made a new node and put in the dates and times 07/06/08 07:00pm to 07/06/08 08:00pm and clicked the preview button. While the times in the boxes were correct (which means it's probably getting submitted correctly) the times that the preview box was showing are wrong. I then opened up another tab to edit the Date field while using the other one to preview the results. I went down the list of choices for the Timezone Conversion. (Site Timezone, Date Timezone, User's TImezone, UTC, and None) then I worked my way back up.

Site Timezone: -9 hours off
Date Timezone: -4 hours off
User's Timezone: -9 hours off
UTC: +4 hours (this is correct)
None: +4 hours

Then back up:
None: +4 hours
UTC: +4 hours
User's Timezone: -4 hours off
Date Timezone: -4 hours off
Site Timezone: -9 hours off

For some reason, when I selected user's timezone when working backwards, it came up as -4 hours, instead of -9 hours. Does that have something to do with this?

karens’s picture

karens commented

We need to differentiate between preview results, the actual value that is saved in the database, the way the node looks when you view it, and whether a previously-saved node has the right values in the edit form when you go to edit it. All of those are completely different situations with different possible results. The original issue here seems to be editing a node and not seeing the right results in the view. For me this works correctly in both PHP 4 and PHP 5 when using absolutely latest -dev version of the code.

There is an existing issue about a problem in the preview, which is different and can't be mixed into this issue because the preview may not look the same as the actual display.

compuguru’s picture

compuguru commented

Hmm, ok. That makes sense. Here's what I found.

I have the Timezone Conversion set to Site's Timezone. Created a new node using times 7:00pm - 8:00pm. After I submitted it shows times of 3:00pm - 4:00pm (-4 hours from the original). Values stored in the database are 2008-07-06T22:00:00 and 2008-07-06T23:00:00.

Went back to edit it. Times in the field show 11:00AM - 12:00PM (-8 hours). Changed it back to the correct time. Still shows 3:00pm - 4:00pm after done editing. Value in the database hasn't changed. Went back to edit mode one last time, showed 11:00am - 12:00pm in the fields. Did not change anything, just clicked submit. Time now shows 7:00am - 8:00am (-12 hours). Database now shows 2008-07-06T14:00:00 and 2008-07-06T15:00:00

This occurs for all the previously saved nodes I tried to edit too.

Not sure if this has anything to do with it, but the difference between what show up on the screen and what is stored in the database is -7 hours. Are these supposed to be UTC values? We're at UTC -5 hours I believe..

karens’s picture

karens commented

OK, it's helpful to see this (even though I can't replicate your results). I need to know a few more things:

1) What version of PHP are you using?

2) What kind of field and widget are you using (easiest is to just use Content Copy to export the field so I can see all the settings).

3) What timezone is your site? What timezone is your server (might not be the same)? What timezone is your SQL server (might not be the same)? If you are using user-configurable timezones, what timezone are you personally using?

The value stored in the database should be UTC unless you selected the option for 'No timezone conversion', when it should stored exactly the value you entered.

karens’s picture

karens commented

Never mind #1, I see your answer above. I have been fixing a number of PHP 4 bugs, so it's possible you still don't have all my changes. I been testing this heavily in PHP 4 -- in PHP 5 there seems to be no problem.

compuguru’s picture

compuguru commented

Sitewide Timezone if America/Chicago, Personal Timezone is America/Chicago, FTP Server seems to be on Eastern Time (+1 hours from me), I don't know how to get the current time from my SQL Server though. I did turn off user Configurable timezones to see if that helped, but it didn't. I also noticed that the example format time under where the date/time is supposed to be entered is one hour ahead of my current time, but the the publishing times on the nodes and logs are correct.

$content[type]  = array (
  'name' => 'Crew Meeting',
  'type' => 'crew_meeting',
  'description' => 'All meetings that involve the Crew but are not outings go here.',
  'title_label' => 'Meeting Type',
  'body_label' => '',
  'min_word_count' => '0',
  'help' => '',
  'node_options' => 
  array (
    'status' => true,
    'promote' => true,
    'sticky' => false,
    'revision' => false,
  ),
  'comment' => '2',
  'old_type' => 'crew_meeting',
  'orig_type' => '',
  'module' => 'node',
  'custom' => '1',
  'modified' => '1',
  'locked' => '0',
);
$content[fields]  = array (
  0 => 
  array (
    'widget_type' => 'date_popup',
    'label' => 'Dates',
    'weight' => '-4',
    'default_value' => 'blank',
    'default_value_code' => '',
    'default_value2' => 'blank',
    'default_value_code2' => '',
    'input_format' => 'm/d/Y h:i:sA',
    'input_format_custom' => '',
    'year_range' => '+3',
    'increment' => '1',
    'advanced' => 
    array (
      'label_position' => 'above',
      'text_parts' => 
      array (
        'year' => 0,
        'month' => 0,
        'day' => 0,
        'hour' => 0,
        'minute' => 0,
        'second' => 0,
      ),
    ),
    'description' => '',
    'group' => false,
    'required' => '1',
    'multiple' => '0',
    'repeat' => 0,
    'todate' => 'optional',
    'granularity' => 
    array (
      'year' => 'year',
      'month' => 'month',
      'day' => 'day',
      'hour' => 'hour',
      'minute' => 'minute',
    ),
    'output_format_date' => 'm/d/Y - g:ia e',
    'output_format_custom' => '',
    'output_format_date_long' => 'l, F j, Y - g:ia',
    'output_format_custom_long' => '',
    'output_format_date_medium' => 'D, m/d/Y - g:ia',
    'output_format_custom_medium' => '',
    'output_format_date_short' => 'm/d/Y - g:ia e',
    'output_format_custom_short' => '',
    'tz_handling' => 'site',
    'timezone_db' => 'UTC',
    'repeat_collapsed' => 0,
    'field_name' => 'field_dates',
    'field_type' => 'date',
    'module' => 'date',
    'label_position' => 'above',
    'text_parts' => 
    array (
    ),
  ),
  1 => 
  array (
    'widget_type' => 'text',
    'label' => 'Agenda',
    'weight' => '0',
    'rows' => '20',
    'description' => '',
    'default_value_widget' => 
    array (
      'field_agenda' => 
      array (
        0 => 
        array (
          'value' => '',
        ),
      ),
    ),
    'default_value_php' => '',
    'group' => false,
    'required' => '1',
    'multiple' => '0',
    'text_processing' => '0',
    'max_length' => '',
    'allowed_values' => '',
    'allowed_values_php' => '',
    'field_name' => 'field_agenda',
    'field_type' => 'text',
    'module' => 'text',
  ),
  2 => 
  array (
    'widget_type' => 'text',
    'label' => 'Minutes',
    'weight' => '1',
    'rows' => '20',
    'description' => '',
    'default_value_widget' => 
    array (
      'field_minutes' => 
      array (
        0 => 
        array (
          'value' => '',
        ),
      ),
    ),
    'default_value_php' => '',
    'group' => false,
    'required' => '0',
    'multiple' => '0',
    'text_processing' => '0',
    'max_length' => '',
    'allowed_values' => '',
    'allowed_values_php' => '',
    'field_name' => 'field_minutes',
    'field_type' => 'text',
    'module' => 'text',
  ),
);
PeteS’s picture

PeteS commented

I think I had the same issue when trying to get the new Date/Calendar versions to work (tried RC first, dev second) with a similar setup as above. There seem to be some major inconsistencies in the way Date and/or Calendar are handling timezones in the new versions, and from a site developer point of view it's pretty nearly impossible to diagnose because it honestly works fine for one node, but for a different but similar node with the same field the date will get shifted for no apparent rhyme or reason. For example, I have had it where I enter a date, say 7:00pm-11:00pm. When I save, the calendar says that the event is from 11:00pm to 3:00 am the next day; when I go back to edit the event, the date will now say something random like 2:00AM to 5:00AM the next day. For now I'm just going to revert back to the stable release and not deal with repeating events, but I just wanted to draw some additional attention to this issue.

karens’s picture

karens commented

Getting date handling working right in PHP4 is harder than heck. Every time I fix one thing something else breaks, and all the while almost everything works perfectly in PHP 5.2 with very little effort. I really wish I could require PHP 5.2, it would save me a HUGE amount of time, but I know there are still lots of people stuck on PHP 4.

I'm still working through the most recent PHP 4 bugs :(

Gidgidonihah’s picture

Gidgidonihah commented

Karen, just require it. Make the whole world upgrade. It's better for us in the long run :)

Seriously, though, you're doing a great job trying to make everything work. I just wish I knew how I could help you better.

karens’s picture

karens commented
Status: Active » Postponed (maintainer needs more info)

OK, I found some places where the PHP4 wrapper was not correctly computing timezone adjustments and committed some fixes. Fingers crossed :/

compuguru’s picture

compuguru commented
Status: Postponed (maintainer needs more info) » Active

Hmm, still no luck. Same issue with the times (-4 hours off). I'm currently looking into upgrading to PHP5 though, so you don't have to worry about this, unless you would like me to do some more testing....

Gidgidonihah’s picture

Gidgidonihah commented

Compuguru, I had some problems with this module too. Stupid 2038 bug. We ended up putting php 5.2 on the server and it's been great. You won't regret it :)

Still doesn't solve the problem for other people though. And I'm sure Karen wants to get it solved and working for everyone. Am I right?

torgospizza’s picture

torgospizza
he/him
Primary language English
Location Portland, OR
commented

I upgraded to the latest stable version, and my time in Watchdog is now displaying in GMT. It appears to only affect times formatted as Short. For instance (and also of note), in the Admin > Date/Time config, the Long format shows the correct date and time (currently 10:48 am PST) but all Short dates show GMT, which is 5:43 pm.

EDIT: Probably can disregard my post. It appears to be an issue with configurable Time Zones. Yeah, I'm an idiot sometimes :)

karens’s picture

karens commented
Status: Active » Postponed (maintainer needs more info)

I would like to get to the bottom of this if anyone can give me a reproduceable example of something that does not work in the latest rc, with complete info about the version of PHP and an export of the field so I know *exactly* how it's set up. So far things work fine for me. Until someone can give me enough info so I can reproduce the bug, there's no way I can do anything.

sprugman’s picture

sprugman commented

Just upgraded to the latest RC on my php 4.4.4 setup. So far it seems to be working fine. (I'm not doing any time zone adjustments in mine, though.)

Offlein’s picture

Offlein commented

..For what it's worth (not much, I know) I experienced this problem, still, with the July 10 release.
You prompted us to switch to PHP5, which works like a dream. Gidgidonihah may have been right.

Dash’s picture

Dash commented

Just upgraded to latest dev - I have PHP4 and am having this problem - also all my events are now appearing on the 1st of each month in month view, which I'm presuming is somehow related to this problem?: http://www.skipthebudgie.org/event if you look at day view they are in the right place, with the wrong times... (the ones in red are imported from another web site and appear on the correct days)

I'll ask my host about php5...

Dash’s picture

Dash commented

Changed to the 5.x-2.x-RC3, which put the events on the right days, but the time is still way off.

karens’s picture

karens commented

Dash - it looks like you are reporting a problem in the way the Calendar displays the times, not the time in the original node. And it looks like it's displaying the right 'from' time, but getting the 'to' time wrong. That's a completely different issue than the others, this issue is about problems displaying the time in the node itself. You should report your remaining issue on the Calendar issue queue since I don't think that's one anyone else has reported and it appears you have the right results in your nodes.

Unless your problem is that your *nodes* have the wrong times. If that's the case there isn't enough info here to reproduce your problem -- the type of date field and widget you're using, the timezone settings for the datefield, your site, and your personal timezone, and example of a date you entered that produces the wrong results, etc.

PeteS’s picture

PeteS commented

I finally got it to work. The confusion is that the module description refers to PHP 4 versus PHP 5.2. This gave me the impression that having PHP 5.x was enough to avoid the "PHP 4 Emulation." But PHP 5.0.x does not have the date functions either, so I was getting the emulated functions instead of the real ones because I thought I just needed to have -any- version of 5. Therefore, I would highly recommend clarifying that the new date functions only exist in 5.2.x, or whatever the specific version cut-off is (I think I read that the new date functions were introduced in 5.1.x, but I may be wrong).

Also, I would agree with those who would say that it should be limited to 5.2.x. The emulated functions are clearly buggy, or at least interact unpredictably with various versions of PHP, so I think it's a much better idea to declare that Date 2 requires PHP 5.2, and link the modules to PHP 5.2 to avoid the confusion that I had.

So for all of those who are still having trouble who are not using 4.x, double check your version and make sure you're not using 5.0.x, which is not going to do you any good despite being PHP 5.

karens’s picture

karens commented

The reason I'm trying to make it work in PHP versions less than PHP5.2 is that there are a number of people who have no alternative right now, and my host is one of the hosts that does not yet offer PHP5.2, so I'm in this boat too.

The functions are certainly not perfect, but they work for me and for many or most others in most situations. I think we're down to the point where there are isolated bugs that still need to be swatted. There's also a performance hit, but it's not noticeable in many places.

As to the PHP4 vs PHP5.0 vs PHP5.2 I think it very clearly tells you that you need PHP5.2 to avoid the need for the emulation code, I say that on the project page, in the included documentation, in the Drupal.org online documentation, and in the module description on the modules page. It's confusing that it's called the 'PHP4' module, but that's better than calling it the 'PHP Less Than 5.2' module, and I don't know what else to call it.

And I say in all these places and in every issue that if you have the ability to get on a server that uses PHP5.2 you should do it.

So to be clear, PeteS are you saying that your problem was that you weren't using the PHP4 module or that you moved to a PHP5.2 server?

PeteS’s picture

PeteS commented

I completely understand about wanting to support older PHP versions. It's a shame that older versions seemingly create so many obstacles for you to, as you mentioned, get it working for one without it breaking in another. My problem was that I was using PHP 5.0.4, I think it was, and some combination of that PHP version and any other part of my server setup was not cooperating with the PHP 4 date functions.

This afternoon, prior to realizing that I needed 5.2.x and not just 5.x, I added some print statements to the routine that generates the specific dates for a recurring date, and saw pretty easily how it was taking the start date, which was at 1:00, and then randomly shifting forward and backward by a few hours from one week to the next.

In either case, thanks again for your work in trying to make it work; the easiest solution for me for the time being was to just upgrade PHP to 5.2, which seemed to completely resolve the problems I had been having.

emok’s picture

emok commented

Hi. I understand it is hell to try to debug these issues with timezone, daylight savings time and PHP versions wth errors.
I posted a comment to "Beware gmmktime()" with some results that I did not find reported elsewhere.
The bottomline is that gmmaketime is buggy in PHP4, as you already know. But to me it seems better to omit the is_dst-parameter when on PHP4.3.11 (not on PHP5). I understand if such a change will not be commited unless extensively tested.
I was using the tarball from 11 July, for 6.x. Will switch to current tarball soon.

karens’s picture

karens commented
Status: Postponed (maintainer needs more info) » Active

OK, there may be a clue here. That 'beware gmmiktime' problem is one of the reasons I created the 5.2 version -- to get that out of the code completely. Unfortunately, in versions less than PHP 5.2 you can't completely get away from it and it still rears its ugly head in some of the PHP4 wrapper code. I need to dig into that and see if there is any way to get rid of the remaining places where it's used.

sprugman’s picture

sprugman commented

This seemed to be working in the beta version, but I'm still having problems with this in the latest 6.2 dev (CHANGELOG.txt,v 1.1.8.77 2008/07/22 14:41:43), which I switched to in order to get date filtering working in views.

Any news? ETAs? Things I can help with? (I don't mean to be pushy, but this holding some things up for me.) I'm starting to wonder how hard it would be to make a DateFieldLite that just takes str_to_time as entry, stores a timestamp, doesn't do anything with timezones, and allows views filtering....

Thanks for all the work.

karens’s picture

karens commented

I finally found an environment where I can reproduce this, so now I can work on a solution. Before I was just shooting in the dark because I couldn't reproduce it.

Unfortunately, I have some personal business I have to take care of that will slow things down, but I'll get to this ASAP.

karens’s picture

karens commented
Status: Active » Fixed

I think I finally got this working right. I found several small problems that contributed, one of the was the dst setting noted by emok. I just committed these fixes, so obviously they won't show up in the tarball until tonight at the earliest.

sprugman’s picture

sprugman commented

seems to be working now, thanks!

Dash’s picture

Dash commented

Well.... latest versions and I'm down from 4 hours late to 2...

karens’s picture

karens commented

What is 'latest versions'? I just created a new rc4 version. Is that what you're talking about? If not, try that version.

Dash’s picture

Dash commented

I'm using the latest 5.x-2.x-dev of calendar and date.

After today's update - nothing has changed (still on php4) at http://www.skipthebudgie.org/event, events which I set up with a start time of 20:00 - 23:00, show on the month view as 22:00 - 00:00, when you go into the event node it is 22:00 - 01:00 (next day), and when I go in to edit them the times are 21:00 - 00:00

am I the only one with this problem?

karens’s picture

karens commented

Use the new rc version. It's hard to know if your -dev version has everything in it. If you have problems in the latest rc version change the version number in this report and re-open it. Part of the reason for issuing the rc was so I could establish exactly what code is being used for any remaining problems.

The behavior you describe was definitely in earlier code and is now fixed for me and apparently for others.

Dash’s picture

Dash commented

That's fixed it, thanks!

murfi’s picture

murfi commented

it's working on php 4.4.4
thanks

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

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