WordPress.org

Making WordPress.org

Opened 6 months ago

Last modified 7 weeks ago

#4480 new enhancement

Event API returns date/time information without timezone

Reported by: Rarst Owned by:
Milestone: Priority: low
Component: Events API Keywords:
Cc:

Description

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".

Change History (6)

This ticket was mentioned in Slack in #core-datetime by rarst. View the logs.


6 months ago

This ticket was mentioned in Slack in #meta by tellyworth. View the logs.


6 months ago

#3 @tellyworth
6 months ago

  • Keywords reporter-feedback added

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?

#4 @Rarst
6 months ago

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.

#5 @dd32
6 months ago

  • Keywords reporter-feedback removed
  • Priority changed from normal to low

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.

#6 @dd32
7 weeks ago

  • Component changed from API to Events API
Note: See TracTickets for help on using tickets.