Hi all,

I'm using this module called Leaguesite to create a website for a soccer team. The developer of the module has added a field for a match to add date/hour to a match. Everything works great but when i add a match in summer (now) it stores in database like this: 1279126800 (translated: Wed, 14 Jul 2010 19:00:00 +0200). However when i add a match in winter it stores my date/hour like this: 1290866400 (translated: Sat, 27 Nov 2010 15:00:00 +0100).

Is this normal?

The thing is... when i view my node it shows the hour i've filled out in the form so that's great. But when i call this match_time from a view, it gives 16:00 instead of 15:00 for the date in november.

Anyone knows how to solve this problem please? Are the hours stored correctly with the +1 and +2? Or is the error in the storage already? Or is the storage ok and should i have a view handler which takes care of DST?

Thanks in advance!

grtz Tim

Comments

timbraeckman’s picture

timbraeckman commented

Anyone? Please?

arlinsandbulte’s picture

arlinsandbulte commented

Pretty sure this is normal behavior due to daylight savings time functions.
I think you need to use date api functions to handle the various timezone & DST 'issues.'
Personally, I prefer not to use the Datestamp format.

timbraeckman’s picture

timbraeckman commented

Thanks for your reply! You think i'll need a view handler which takes care of DST ?

imclean’s picture

imclean commented
Version: 6.x-2.4 » 6.x-2.6

I'm having the same problem. In my case, the timestamps imported from a CSV file are the correct times taking into account DST. The timestamps are stored correctly in the DB. When displaying the dates, Drupal adds the DST offset of +1 hour to all times which occur during the daylight savings period, putting the times out by 1 hour.

Further info:

- Currently it is DST in my part of Australia
- PHP on the server is aware of DST
- Timezone in Drupal is set correctly to my timezone
- The timestamp fields are correct for the timezone at any time of year, modification for DST is not required.
- Outside Drupal, date() on the server works correctly for all timestamp fields
- A view listing the date field adds 1 hour to all times falling during DST, which makes them incorrect

Related issues:

#924760: If DST begins or ends between From and To dates, dates following the change are incorrect
#939004: Override views_handler_field_date to fix DST problems

imclean’s picture

imclean commented
Version: 6.x-2.6 » 6.x-2.x-dev

Updated version.

Troubleshooting steps: http://drupal.org/node/755312

thinkyhead’s picture

thinkyhead commented

I'm the author of #924760: If DST begins or ends between From and To dates, dates following the change are incorrect

Sounds like dates when being displayed or interpreted need to use the DST in which they fall, and not the current DST. This distinction needs to be parsed out very carefully in the date handling code of Drupal and the various date-centric modules. This kind of bug really messes with people, who know what they intend with things like date intervals, and don't want to concede to the dumbness of the computer. If I use an interface to express "every week at 2pm" then I don't want it to get stupidly turned into "every 168 hours." That turnover in DST needs to be accounted-for by the APIs, for serious.

arlinsandbulte’s picture

arlinsandbulte commented
Status: Active » Closed (won't fix)

Hi,
I am just indiscriminately closing all support requests with no activity for more than 1 year.
If you consider this to still be a valid issue / support request, feel free to re-open.
BUT,
if you are re-opening this issue, please provide specific details on how this issue can move forward.

Thanks.