Unix time (%U) off by 24,400 seconds for Solspace Calendar date variables

Question

SOLVED (see below)

I have a strange error that has cropped up recently. Outputting a Solspace Calendar event's start or end date (and probably the related variables) in Unix time results in a timestamp that is off by 6 hours, 46 minutes, 20 seconds (24,400 seconds). For example, for an event that starts at 8:30 a.m. PST on October 5 {event_start_date format="%U"}, we get 1475657000, which actually corresponds to 1:43:20 a.m. PST on Oct. 5. (We need the Unix time for creating an .ics file.)

However, outputting those dates with standard PHP date format flags DOES show the correct date/time. For example {event_start_date format="%F %j, %Y at %G:%i:%s"} outputs October 5, 2016 at 08:30:00. Also, the Unix time formatting (%U) works correctly for the built-in {entry_date}, etc. variables - just not for custom date variables.

Additionally, I have verified that the server time is correct and the dates/times are correct in the database.

The only thing I could think of was that maybe something has changed in PHP since the module was coded and that is causing an error? We did upgrade PHP a few months ago, and it's possible these dates in Unix format have been incorrect since then. (We are running PHP 5.6.21, EE 2.10.1, Calendar 1.8.14.)

Answer 1

FIX: add tz_id_my-calendar-url-title parameter...

This appears to be a bug introduced in Calendar 1.8.12, where Solspace tried to address a problem in how Unix timestamps were output (they were not getting localized to the timezone, so 8:00 a.m. PDT would output as 8:00 a.m. GMT). Solspace added an undocumented parameter to specify the timezone. See: https://solspace.com/expressionengine/legacy/calendar-1/change_log/#v1.8.12 . Basically, if you want to output date vars as Unix timestamps (%U format), you need to add the tz_id_my-calendar-url-title parameter to your module tag: e.g., tz_id_community-events-calendar = 'America/Los_Angeles'. (This only applies to the custom date variables, like {event_start_date}, and ONLY if you need the Unix timestamp).

I've been in touch with Solspace, so hopefully they are fixing :)