View Issue Details

IDProjectCategoryView StatusLast Update
2921Composrcalendarpublic2016-11-11 20:02
ReporterPDStig Assigned ToChris Graham  
PriorityhighSeverityminor 
Status resolvedResolutionfixed 
Summary2921: get_calendar_event_first_date converting wrong timezone since end of DST
DescriptionEver 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);
}
TagsNo tags attached.
Attach Tags
Time estimation (hours)
Sponsorship open

Sponsor

Date Added Member Amount Sponsored

Activities

PDStig

2016-11-06 20:00

administrator   ~4526

Server is reporting UTC time, so it's not the server clock

Chris Graham

2016-11-09 23:19

administrator   ~4533

Can you tell me what the e_timezone field from the database is?

Chris Graham

2016-11-09 23:22

administrator   ~4534

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.

PDStig

2016-11-10 00:45

administrator   ~4536

e_timezone in all events is America/New_York

Chris Graham

2016-11-10 00:53

administrator   ~4537

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.

PDStig

2016-11-10 01:27

administrator   ~4538

Last edited: 2016-11-10 01:28

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.

Chris Graham

2016-11-11 17:51

administrator   ~4544

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.

Chris Graham

2016-11-11 20:02

administrator   ~4545

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.

Issue History

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