Currently date_create() is used to in D6 to create datetime objects. There is a comment in the code stating that with UNIX Datestamps the passed in time zone will be ignored and UTC will be assumed. My experience of this function has been different. The PHP docs are not very clear about this.
I found that it uses the server time zone or set time zone to offset the date.
EG:
Current site time zone = Africa/Johannesburg (AKA +2:00).
Date set in form fields = to 1 FEB 2012 = 1328047200
Expected value returned by date_create = 2012-02-01 00:00:00
Returned value = 2012-01-31 22:00:00
This will cause your date to be displayed incorrectly. If you using Year+Month granularity the date will display the previous month. If you are using Year granularity it will display the previous year because 1 Jan 2012 0:00 - 2 hours = 31 Dec 2011.
This does not seem to be a problem with the other date types.
There is a work around in place that tries to change the offset back but this only works when the server time zone is the same as the passed in time zone.
The date_convert() function has a comment above stating:
A variety of ways to convert dates from one type to another. No timezone conversion is done in this operation, except when handling timestamps because create_date() assumes timestamps hold the UTC value for the time.
If no time zone conversions should be done here I think the best way forward is to first convert the timestamp to a format that is not affected.
EG: FROM
$obj = date_create("@$date", timezone_open('UTC'));
date_timezone_set($obj, timezone_open($tz));
TO:
$obj = date_create(date("Y-m-d H:i:s", $date), timezone_open($tz));
This way timestamps work as expected.
Attached path fixes this in D6 for me.
I think the following issues are symptoms of the same problem and might be related:
#468406: Incorrect setting of db_timezone when date cck field set to "No time zone conversion"
#920534: Date CCK Field ignore "No time zone conversion" option when setting date with granularity = day
#1080354: Date with granularity months always changes
#605824: Year-field displays as one year early when user's timezone is negative
If anybody is interested in D5 or D7 maybe create a new issue. I would start looking here in the relevant versions.
D5: date_convert() in date_api.module http://drupalcode.org/project/date.git/blob/refs/heads/5.x-2.x:/date_api...
D7: DateObject::__construct in date_api/date_api.module http://drupalcode.org/project/date.git/blob/refs/heads/7.x-2.x:/date_api...
I have not done any testing any other versions.
| Comment | File | Size | Author |
|---|---|---|---|
| date-datestamp_tz-D6.patch | 671 bytes | NaX |
Comments
Comment #1
NaX commentedHere is another way of achieving the same fix using the current workaround but I think the original patch is a better method.
I don't fully understand how date_create() is calculating the offset. I think it is the difference between current time zone and UTC. The server/session time zone seems to be set by Drupal/Date and api if not set PHP tries to guess the current time zone.
REF docs:
DateTime::__construct
date_default_timezone_get
Comment #1.0
NaX commentedAdded time stamp to example
Comment #2
damienmckennaUnfortunately the Drupal 6 version of the Date module is no longer supported. That said, we appreciate that you took time to work on this issue. Should this request still be relevant for Drupal 7 please feel free to reopen it. Thank you.