A continuation of #1380350: Date View queries don't compensate for daylight savings time: causes missing all-day events and events near midnight. Date Views handles most queries by taking the value stored in the database (which is usually but not always in UTC) and adds the timezone offset to that value, then compares the result to the local date. We handle different offsets created by DST by creating an offset that is based on the current date.

We check to see if the database has built-in timezone support. If it does, we let the database do the adjustment. If it doesn't we have to rely on the offset we are computing.

We can make the right adjustments to normal Views queries for DST changes in the offsets, but I can't see any good way to make the right adjustments to summary queries. In a summary query, every date in the database is formatted into a formatted date, then the formatted dates are grouped to get a count and create a link to the view for that date. If the database does not have built-in timezone support, we have to use a single offset -- every date will be adjusted by that offset, which will sometimes be the right offset and sometimes not.

The only alternative I can see would be to add columns for the offset to the table where we store the field value. Then the formatted date would be the sum of the raw date field and the offset field, formatted by the database into the final result. That would still not fix system dates or or any date that is not a field, because we won't have offsets for those.

I'm not sure what is the right solution for this, but it probably requires some architectural changes, so it is postponed until we start a new branch.

Comments

steinmb’s picture