Skip to:

Opened 3 years ago

Closed 3 years ago

#8536 closed enhancement (fixed)

Add GMT dates to component objects

Reported by: espellcaste's profile espellcaste Owned by: espellcaste's profile espellcaste
Milestone: 10.0.0 Priority: normal
Severity: normal Version: 9.0.0
Component: REST API Keywords: has-patch has-unit-tests


WordPress core has GMT dates to most, if not all, objects that support date. BuddyPress doesn't follow this unwritten "rule". Component objects such as Activity, Group, Friendship, etc add dates in the object response but not their GMT version.

This request came up recently,, to add GMT dates to the BP REST API endpoints and instead of adding GMT dates in the endpoints response in the plugin, I'd like to properly add support in BuddyPress core and use it there.

Since there is no standard to the names of the dates in the components currently, I'd probably just follow the names adding _gmt to the end.

Here is an example from the BP_Groups_Group class:

  • date_created
  • date_created_gmt

Change History (8)

#1 @espellcaste
3 years ago

  • Summary changed from Add GMT gates to component objects to Add GMT dates to component objects

#2 @r-a-y
3 years ago

Correct me if I'm wrong, but shouldn't BuddyPress already be saving all dates into the DB as GMT?

For example, the date_created field for BP_Groups_Group is saved as GMT by default, unless another plugin changes it.

#3 @espellcaste
3 years ago

Thanks @r-a-y, you are correct. I was able to confirm in several objects (Activity/Message/Group/Friends) that all dates are on GMT. They are saved as GMT unless set otherwise.

Currently, this is wrongly set on the schema of all endpoints where date is used. In the BP REST API: it says the dates are in the site's timezone where actually they are in GMT. They are all using bp_rest_prepare_date_response which converts the date to a proper ISO8601 format.

There are two possible approaches here:

  • One would be to change the schema to indicate the dates are on GMT instead of the site's timezone. This would not change the current date format.
  • The other one would be to update the default date field so that it is in the site's timezone and add a new key with _gmt as suggested in the description of this ticket.

The second option is a break-ish change since we are changing the "nature" of the date from GMT to the one set in the site's timezone.

cc: @imath (I'd love your feedback on this one).

#4 @espellcaste
3 years ago

Another argument to use the second option is that currently, we are leaving up to the API consumer to update/format the date, currently in GMT, to its correct format (whatever the timezone is). WordPress core follows the format of having the site's timezone and a GMT version of the date.

Ideally, we should follow WP core and have a GMT version and one with the site's timezone.

#5 @imath
3 years ago

Hi @espellcaste

I think we should add a GMT date property to all items schema having a date property.

Use the db value for this date property, and convert this value to site tmz date to set the corresponding date property.

#6 @espellcaste
3 years ago

Tks for the feedback! So, option b. I'll proceed with that. :)

#7 @espellcaste
3 years ago

  • Component changed from Core to REST API

#8 @espellcaste
3 years ago

  • Keywords has-patch has-unit-tests added; needs-patch needs-unit-tests removed
  • Resolution set to fixed
  • Status changed from assigned to closed

Resolving this ticket since its code was merged at

Note: See TracTickets for help on using tickets.