Event API returns date/time information without timezone

[Rarst]

API responses for events have local date and time without timezone, e.g. "date": "2019-06-18 19:00:00".

This causes very confusing core code logic for processing them and makes it hard to make use of it in general.

I would strongly encourage to add a field with a fully parseable, meaningful, and timezoned data, e.g. "date-rfc3339": "2019-06-18T19:00:00+02:00".

[tellyworth]

It seems that the times aren't tracked with an explicit TZ, and are instead assumed to be in the local time at the venue.

Given that context, what's the correct way to handle this? I'm not certain we necessarily know the literal TZ. Would it be sufficient to simply document that it's in the venue's TZ?

[Rarst]

It seems that the times aren't tracked with an explicit TZ, and are instead assumed to be in the local time at the venue.
Given that context, what's the correct way to handle this?

Correct way would be to figure out and serve time zone.

For display purposes exclusively local time would be fine. But when it starts getting used for comparison (and it does in core) that leads to pretty bizarre code and logic.

WP is used to throw local times at everything and a lot of it is severely bugged as result. Let's move this in a right direction.

[dd32]

We do have an explicit UTC Offset in the Meetup response, but IIRC it's not entirely trustable other than to determine the local time of an event. WordCamp data also has no notion of a timezone, only dates.

I think as a way forward we need to start a) storing the event times as UTC and b) storing an offset, we can then look at the data to work out if it's anywhere near reasonable for use, and can then start moving clients over to using some new date fields (Even though we might just end up returning a Local Date+Time and a UTC Offset field)

I'm marking this as low, as it's working as intended - it was a deliberate design decision made at the time, but we do want to make it more reasonable.

[iandunn]

x-ref ​https://github.com/WordPress/wordcamp.org/issues/226

[iandunn]

This is worse now that we have lots of online events, where people can easily attend from outside the local timezone.

It's even worse than that for ​the learn.w.org discussion groups, which are only online, and not tied to any particular geographic location. Meetup.com still requires groups to pick a location, though, so it has San Francisco listed. So users all over the world see those events in Pacific Daylight Time.

Luckily, @ryelle already added a UTF offset column in r9632, for ​the online events page.

I think we can just use that to add date_utc and end_date_utc fields to the API endpoint. I'll look into that.

[Rarst]

Note that storing future events in UTC is generally not preferable due to unknown future state of time zone offsets. Something scheduled for 6pm local time should stay scheduled for 6pm local time regardless if government decides to cancel summer time or whatever. Storing in UTC doesn't accomplish this, it will drift whenever timezones table changes.

This is a big reason why we dropped moving WP core towards canonical UTC for time storage (so far).

[dd32]

Replying to iandunn:

It's even worse than that for ​the learn.w.org discussion groups, which are only online, and not tied to any particular geographic location. Meetup.com still requires groups to pick a location, though, so it has San Francisco listed. So users all over the world see those events in Pacific Daylight Time.

For online events, could we perhaps leverage the fact that WordPress sends it's timezone with the Events API request, and convert online events into the requests TZ?

Passing the Time + Timezone back to core is obviously important for display in future, but for existing clients, Time + Assumed Local Time is probably just as useful immediately.

[iandunn]

🤔

Core only sends the timezone when the user manually enters a city to search for. Most of the time the events are fetched via IP geolocation, and Core doesn't send the TZ then (for privacy).

When the API does get the TZ, it uses it to disambiguate searches, like Portland, Orgeon vs Portland, Maine. Once it returns the events in that city, though, they're cached by Core and shared by all users who request events in that city. In most cases they'll probably be the same TZ, but there are some edge cases that feel significant, like users who are on opposing sides of a timezone border, and those who are traveling.

It feels safer to give Core the absolute data, and then it can format it based on the current user's timezone.

[iandunn]

I opened ​#core51130 for updating the Events Widget.

[iandunn]

WIP adding date_utc, end_date_utc fields

[iandunn]

4480.diff​ is a WIP that adds date_utc and end_date_utc fields to the response, with Unix timestamps. The local date and end_date fields are left, for back-compat.

I played around w/ using RFC3339, because I agree it's more correct for future dates. In this context, though, it doesn't seem likely to make an impact, and it seemed to add extra complexity between the different data sources, syncing, converting, etc.

I agree that greenfield code should use it, though.

[dd32]

Replying to iandunn:

Core only sends the timezone when the user manually enters a city to search for. Most of the time the events are fetched via IP geolocation, and Core doesn't send the TZ then (for privacy).

Ah :/ Well I guess it's core-patch route then :)

[Rarst]

Not sure about names for the new fields, if they will hold timestamps they might be better named as such? Seems confusing that date field is a string, but date_utc is a timestamp. timestamp and timestamp_end maybe?

strotime() for reversing timestamps is flawed. Is there now better time zone information than seconds offset to use?

Also I still would like to see API response contain event time zone somewhere, if it's now available? That's just meaningful to have, even if core won't use it right now.

Gave wrong direction conversion example, not awake yet, edited out. :)

[Rarst]

Ok, correct conversion of a local time string into timestamp would be something like $datetime = date_create( $date, wp_timezone() )->getTimestamp(); in core (loose example, check that it's not false, etc). Having a meaningful time zone string there is preferable to offset (because summer time craziness and stuff).

[iandunn]

Replying to Rarst:

Is there now better time zone information than seconds offset to use?

For meetup events, we only have the offset in the database, because that's the only TZ info that ​Meetup.com's `:urlname/events` endpoint provides.

For WordCamps, ​we only have the WP timestamp, with `00:00` for the time, so really just the local date. We could add TZ info here, but I think that's out of scope for this ticket, and a lower priority.

Seems confusing that date field is a string, but date_utc is a timestamp.

That's a great point. I was trying to maintain consistency w/ the existing fields, but clarity is more important.

[iandunn]

🤔, actually, it would probably be confusing if the Events Widget displayed meetups in the user's local time, but WordCamps in the venue's timezone. So I guess we'll need to ​add Unix timestamps to the WordCamp API endpoint as well.

[Rarst]

Need to be careful that nothing offline gets shown in the wrong day.

I start to think that online events being thrown in the mix means that this needs to be redesigned in dashboard widget. Offline and online event are two very different things with different implications for user.

[iandunn]

In 10244:

Official Events: Store WordCamp UTC offset.

This is needed for the Events Widget to display events in the user's timezone. We're already storing it for meetups, and it was recently added to the WordCamp.org API as well.

See ​https://github.com/WordPress/wordcamp.org/issues/567
See #4480
See ​#core51330

[iandunn]

complete version of 4480.diff

[iandunn]

4480.2.diff​ feels ready to me. I'll commit it next week unless y'all see any problems.

Ignore the coding standards comment, I'll remove that before committing.

[iandunn]

In 10270:

Events: Add start_unix_timestamp and end_unix_timestamp fields.

The date and end_date fields are WP timestamps which reflect the event's local timezone. True Unix timestamps are needed for the Events Widget to display events in the user's local timezone.

Fixes #4480
See ​#core51130
Props Rarst, dd32, iandunn