Respect user's time zone when creating an absence #11

edwardloveall commented 2025年08月12日 17:27:11 +02:00

I also inlined all the let, before, and subject pieces of the spec/requests/absences_spec.rb in its own commit. This would be a good one to review one commit at a time.

https://gitlab.com/food-rescue-alliance/tomato/-/issues/210

A user can only automatically create an absence when the absence starts at least 7 days out. 6 days will result in a "too soon" error. However, we sent time stamps with the user's system offset (as they appear in
UTC) when scheduling an absence.

This is a problem because if the user is in a different, earlier timezone, selecting an absence starting 7 days from now is actually a little behind.

For example, if the volunteer has their time zone set to Los Angeles, but is currently in New York, they will submit an absence that looks like this:

{
	"ends_at": "2025年08月19日T04:00:00.000Z",
	"starts_at": "2025年08月19日T04:00:00.000Z"
}

The server used to take that time stamp and compare it to Absence::ABSENCE_LEAD_TIME.from_now.beginning_of_day which is parsed as the volunteer's time zone:

Absence::ABSENCE_LEAD_TIME.from_now.beginning_of_day
# 2025年8月19日 00:00:00.000000000 PDT -07:00

When the two are compared, starts_at is later than the cutoff time.

To fix this, we first convert the starts_at to a date. This is how the database stores the data already, and it also ensures that a few hours difference won't matter.

This does not solve the problem if the user is in a time zone that is currently a different date than their set zone. We're not solving that right now.

_I also inlined all the `let`, `before`, and `subject` pieces of the `spec/requests/absences_spec.rb` in its own commit. This would be a good one to review one commit at a time._ https://gitlab.com/food-rescue-alliance/tomato/-/issues/210 A user can only automatically create an absence when the absence starts at least 7 days out. 6 days will result in a "too soon" error. However, we sent time stamps with the user's system offset (as they appear in UTC) when scheduling an absence. This is a problem because if the user is in a different, earlier timezone, selecting an absence starting 7 days from now is actually a little behind. For example, if the volunteer has their time zone set to Los Angeles, but is currently in New York, they will submit an absence that looks like this: ```json { "ends_at": "2025年08月19日T04:00:00.000Z", "starts_at": "2025年08月19日T04:00:00.000Z" } ``` The server used to take that time stamp and compare it to `Absence::ABSENCE_LEAD_TIME.from_now.beginning_of_day` which is parsed as the volunteer's time zone: ```ruby Absence::ABSENCE_LEAD_TIME.from_now.beginning_of_day # 2025年8月19日 00:00:00.000000000 PDT -07:00 ``` When the two are compared, `starts_at` is later than the cutoff time. To fix this, we first convert the `starts_at` to a date. This is how the database stores the data already, and it also ensures that a few hours difference won't matter. This does not solve the problem if the user is in a time zone that is currently a different _date_ than their set zone. We're not solving that right now.

edwardloveall commented 2025年08月13日 21:55:07 +02:00

I suspect it would be probably a decent amount of work but we might want to consider how to always have the front end and back end communicate in UTC. Time zone issues can be very sneaky and having the front end on browser time and back end on user's home time zone seems like it may add a level of difficulty when trying to track down bugs like this.

Agreed! The material component that does the date picking just gives this back to you as a time-zone adjusted timestamp, so until I move away from that I have to deal with it. But also, I don't know of a way to set the browser's timezone so the timestamps would still need to be adjusted.

I think the solution here would be to change to an actual <input type="date" /> that would submit something like 2025年08月13日. It's kicking the "volunteer and organization are in a different zone" can down the road, but it's most accurate at the moment.

> I suspect it would be probably a decent amount of work but we might want to consider how to always have the front end and back end communicate in UTC. Time zone issues can be very sneaky and having the front end on browser time and back end on user's home time zone seems like it may add a level of difficulty when trying to track down bugs like this. Agreed! The material component that does the date picking just gives this back to you as a time-zone adjusted timestamp, so until I move away from that I have to deal with it. But also, I don't know of a way to set the browser's timezone so the timestamps would still need to be adjusted. I think the solution here would be to change to an actual `<input type="date" />` that would submit something like `2025年08月13日`. It's kicking the "volunteer and organization are in a different zone" can down the road, but it's most accurate at the moment.

edwardloveall commented 2025年08月13日 21:56:24 +02:00

Flaky tests pass locally.

Flaky tests pass locally.