See #336255-11: CCK datestamp fields totally broken and fields without timezone handling mostly broken for background. I was trying to understand how date field timezone handling works to fix that signup bug. With a lot of debug printing, it appears that if a CCK datestamp field (and I presume it's the same with date or datetime fields, I just haven't tested yet) is configured to use "Site's timezone" for the TZ handling, it actually uses the user's TZ and stores the date as a UTC time with the current user's TZ as the offset. For example:
User TZ == America/Chicago
Site TZ == America/Los Angeles
I created a node with the following start time:
2008 November 20 3:00 am
Upon saving the node, I had this inside $node->field_datestamp[0]:
array(5) {
["value"]=>
string(10) "1227171655"
["value2"]=>
string(10) "1227175255"
["timezone"]=>
string(15) "America/Chicago"
["offset"]=>
int(-21600)
["offset2"]=>
int(-21600)
}
That timestamp actually corresponds to 2008-11-20 01:00 am in America/Los Angeles, the site timezone (or 2008-11-20 09:00 am UTC). I thought if I say "Use the site TZ" and "it starts at 3:00am", it would store 3:00am LA, 5:00am Chicago, and 11:00am UTC. Am I missing something, or is this a bug?
Thanks!
-Derek
Comments
Comment #1
karens commentedNo timezone is stored in the database for anything other than 'date' timezone handing, these timezones are added to the node during node_load so they can be used in date processing. The date that is stored in the database should be correct (the entered date in the user's timezone adjusted back to UTC).
The only place I can see that there could be an issue is that the user's timezone should not get stored in the cached node, so I need to investigate that.
I can't tell if you are actually seeing something that indicates something is broken or that you just thought the logic was wrong.
Comment #2
arlinsandbulte commentedIs this issue still valid?
I have not bothered trying to verify, but I think I see dww's point.
Comment #3
arlinsandbulte commentedNo reply, and according to #336255: CCK datestamp fields totally broken and fields without timezone handling mostly broken this appears resolved anyway.