Query timestamp_add_days doesn't seem to account for daylight savings

If my user says they’re available for the next 4 Mondays, I create four schedule records in my database. I calculate the date of the first Monday, then add 1 week for the second record, add 1 week for the third record, and add 1 week for the fourth record:

Any time they add dates to their “usual” schedule, I always check first to make sure there isn’t already a corresponding record before creating the weekly records. I query all existing records by calculating the first date, then adding 7 days for the second record, then adding 7 days for the third record, etc.

In my testing, this was working great…until November 7, 2021 which happens to be Daylight Savings. So I gather that the filter transform_timestamp takes daylight savings into account when creating a record, but the query filter timestamp_add_days does not take daylight savings into account when looking for a record.

Is there a way for me to manipulate timestamps in queries in a daylight-savings-compliant way?

For the record, I worked out a work-around. Before doing my query, I create a new variable with the previous record’s start time and the transform timestamp filter to add 1 week. I then use that new variable in my query and it corresponds perfectly to the record that was originally created using the transform timestamp filter. I don’t have to use the query’s timestamp_add_days filter at all. Hopefully that will continue to be the case as my app grows and I manipulate the data in new ways.

Hey Erin, I think confusion if because of daylight savings does not affect UTC.

Additionally, daylight savings does not affect Unix timestamps because it is just the amount of seconds (in Xano’s case milliseconds) since Jan 1, 1970 UTC.

But you are saying that those two are off in the by custom query filter. Is the activity_schedule.start_utc stored in UTC or another timezone, as I notice the timezone variable when adding to the DB?