Closed eengoron closed 6 years ago
@eengoron have you set tz_offset
when constructing API client?
Yup! The offset is correct.
Looks like frontend just always sends UTC timestamps and backend assumes UTC without taking tz offset header into account.
Many endpoints do not support X-TZ-Offset (internally tracked as https://github.com/closeio/closeio/issues/1780), as in, they expect you to submit a full timestamp including offset. The header was initially designed for places like Search Queries where it was really necessary (like search queries that use today
).
Supporting the header on endpoints like this isn't really a bug, just something we could add as a convenience, but not necessary. Something I had previously written internally about this issue:
To be clear, even if we added support for it, the header would only be used if
date_start
/date_end
is in a format that doesn't specify the timezone.2014-01-29T00:00:00.000Z
or2014-01-29T00:00:00+00
should not be affected byX-TZ-Offset
becauseZ
or+00
specifically says "this datetime is IN UTC on purpose".Adding support for this would only a convenience for API developers who want to specify simple dates (e.g.
2014-01-29
) without computing offsets themselves.
Closing since this isn't an issue for this repo, regardless.
As an example, today I ran this request:
The response I got back was:
since the bounding dates are 2018-01-01 and 2018-01-01, it means that we aren't correctly factoring in timezone when passing through date params.
We need to add the tz.offset*-1 to the datetime in both directions for it to appear the same as it does in app.