Issue with timezones

[sebduggan]

There is an issue with the way datetimes are pulled from the database and then rendered in the calendar. Let's take an example:

A fixture_date is stored in the database. The query will return the following:

{ts '2019-07-28 13:00:00'}

The data row is then converted to a struct, which sees the datetime as being in the system timezone, like so:

Date Time (Europe/London)
{ts '2019-07-28 13:00:00'}

When this is serialized to JSON, it calculates that this time falls inside British Summer Time, so includes the time offset:

{
    "fixture_date":"July, 28 2019 13:00:00 +0100"
}

When the calendar plugin receives a datetime that includes the offset, it automatically converts that time, so the resulting output is this:

I would suggest that in almost all cases, the datetime you want to display on the calendar will be the actual datetime as stored in the database. So by default, we should convert the calendar event start and end datetimes:

DateTimeFormat( my_date_time, "yyyy-mm-dd HH:nn:ss" )

And then if there are special timezone requirements for an individual scenario, then that could be applied as an override...

[vivienwong]

Hi Seb,

Does DateTimeFormat( my_date_time, "ISO8601" ) work for you? The resulting format to pass to json is 2020-03-29T09:00:00+0100 and it works on my customised function - renders on the calendar as 9am.

I'll push this change into the default function if you can confirm this works?

[sebduggan]

No - that will have a very similar issue, because it includes the timezone offset. The whole point of the change is to remove the timezone...

It's only showing 9am for you because the server and your browser are both set to the same timezone (BST). If you were, for example, to set your server (Lucee) locale to US time (Lucee web admin), you'd see a completely different time displayed in the browser. But using the date mask I suggested, it will always display the actual time of the event, with no adjustment.

[vivienwong]

Thanks Seb. I've made the changes accordingly, closing this issue.