View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
2921 | Composr | calendar | public | 2016-11-06 19:55 | 2016-11-11 20:02 |
Reporter | PDStig | Assigned To | Chris Graham | ||
Priority | high | Severity | minor | ||
Status | resolved | Resolution | fixed | ||
Summary | 2921: get_calendar_event_first_date converting wrong timezone since end of DST | ||||
Description | Ever since the daylight savings time end, get_calendar_event_first_date is not correctly converting times. The times are still being converted from UTC-4 to UTC, instead of UTC-5 to UTC like it should. | ||||
Steps To Reproduce | $radioevents = $GLOBALS['SITE_DB']->query_select('calendar_events', array('*'), array('e_type' => 9), ''); foreach ($radioevents as $radioevent) { $thedate = get_calendar_event_first_date('UTC', false, $radioevent['e_start_year'], $radioevent['e_start_month'], $radioevent['e_start_day'], $radioevent['e_start_monthly_spec_type'], $radioevent['e_start_hour'], $radioevent['e_start_minute'], $radioevent['e_end_year'], $radioevent['e_end_month'], $radioevent['e_end_day'], $radioevent['e_end_monthly_spec_type'], $radioevent['e_end_hour'], $radioevent['e_end_minute'], $radioevent['e_recurrence'], $radioevent['e_recurrences'], false); } | ||||
Tags | No tags attached. | ||||
Attach Tags | |||||
Time estimation (hours) | |||||
Sponsorship open | |||||
|
Server is reporting UTC time, so it's not the server clock |
|
Can you tell me what the e_timezone field from the database is? |
|
I tried to reproduce, with some careful code analysis and testing, and couldn't. I entered a Chicago-zoned event (hour=9) with timezone conversion on, and observed it save into the database with UTC-5 (hour=14) for a 1st Nov date and UTC-6 (hour=15) for a 30th Nov date. In both cases it edited okay and displayed as 9am. I suspect you may have added to the DB using manual code rather than UI, and UTC+- timezones rather than the named timezones. Those would not do any DST handling. |
|
e_timezone in all events is America/New_York |
|
Can you provide more details of the situation... 1) Does it show the wrong time when viewing the event now, but showed the right time before? 2) Can you link me to a specific event with the time you expect in NY time, and the time you expect in UTC time. |
|
1) Viewing the event via. the calendar page shows the right time and did show the right time before as well. It also correctly shifted to UTC-5. The problem lies in the PHP script I created which utilizes the get_calendar_event_first_date function as shown above. What happens is converting it to "UTC" actually causes it to return times in UTC+1. When specifying UTC-1, then it returns UTC time. The script on my server is lovinity.org/check_user.php if you wish to take a look. I don't think I'm doing anything wrong... the function just seems to be returning the wrong timestamps. |
|
I'm really struggling to reproduce this, even with your data. So I'll discuss with you on Skype step-by-step how to reproduce it. I think there may be a wrong assumption somewhere. |
|
It wasn't a bug per se, but the API docs were misleading. That $timezone parameter is the timezone of the event, not the timezone of the viewing user. The timezone of the event is needed so DST shifts can be calculated - events are stored in the DB in UTC but are fixed in the time zone for the e_timezone value of that event - so the UTC time actually varies as you enter/exit DST. If it doesn't know the correct timezone of the event it can't shift the UTC correctly accordingly. The API is not designed to be able to show arbitrary timezoned output, but it can be fudged by changing the TIMEZONE_MEMBER_CACHE global as follows... Code: $GLOBALS['TIMEZONE_MEMBER_CACHE'][get_member()] = 'UTC'; foreach ($radioevents as $radioevent) { $thedate = get_calendar_event_first_date($radioevent['e_timezone'], true, $radioevent['e_start_year'], $radioevent['e_start_month'], $radioevent['e_start_day'], $radioevent['e_start_monthly_spec_type'], $radioevent['e_start_hour'], $radioevent['e_start_minute'], $radioevent['e_end_year'], $radioevent['e_end_month'], $radioevent['e_end_day'], $radioevent['e_end_monthly_spec_type'], $radioevent['e_end_hour'], $radioevent['e_end_minute'], $radioevent['e_recurrence'], $radioevent['e_recurrences'], false); var_dump($thedate[0]); } unset($GLOBALS['TIMEZONE_MEMBER_CACHE']); Note also that I set the 2nd get_calendar_event_first_date parameter to true to force it to display into UTC (the fudged timezone of the viewing user) rather than the event's own timezone. |
Date Modified | Username | Field | Change |
---|---|---|---|
2016-11-06 19:55 | PDStig | New Issue | |
2016-11-06 20:00 | PDStig | Note Added: 0004526 | |
2016-11-09 23:19 | Chris Graham | Note Added: 0004533 | |
2016-11-09 23:22 | Chris Graham | Note Added: 0004534 | |
2016-11-09 23:22 | Chris Graham | Status | Not Assigned => Closed |
2016-11-09 23:22 | Chris Graham | Assigned To | => Chris Graham |
2016-11-09 23:22 | Chris Graham | Resolution | open => unable to reproduce |
2016-11-10 00:45 | PDStig | Note Added: 0004536 | |
2016-11-10 00:53 | Chris Graham | Note Added: 0004537 | |
2016-11-10 01:27 | PDStig | Note Added: 0004538 | |
2016-11-10 01:28 | PDStig | Note Edited: 0004538 | |
2016-11-11 17:51 | Chris Graham | Note Added: 0004544 | |
2016-11-11 20:02 | Chris Graham | Note Added: 0004545 | |
2016-11-11 20:02 | Chris Graham | Status | Closed => Resolved |
2016-11-11 20:02 | Chris Graham | Resolution | unable to reproduce => fixed |