1797693 - "Day" and "Week" calendar views show wrong time for events on a daylight saving (DST) transition day

Status: NEW

(Calendar :: Calendar Frontend, defect, P1)

Description

[pg_78]

Attachment: Screenshot 2022-10-27 095438.png

Steps to reproduce:

• Set system timezone set to "UTC+00:00 Dublin, Edinburgh, Lisbon, London" (this timezone has daylight savings: i.e. it's UTC+1 in summer, reverting to UTC on the last Sunday of October)

• On 27 Oct 2022, create an event from 0800-0900 on 30 Oct 2022 (which is the DST transition day).

Actual results:

• Opening the event shows the time as 0800-0900 (correctly)

• In the "Day" and "Week" grid views, the event is in the 0900-1000 slot (incorrect)

• When you mouse over the event in these views, the tooltip shows 0800-0900 (correctly)

Note: the problem does not occur for an event on 31 Oct 2022 (the day after transition). The issue seems to be specific to events on the transition day itself.

Expected results:

In the "Day" and "Week" grid views, the event should have been shown in the 0800-0900 slot.

Comment 1

[pg_78]

Existing bugs that might be related but are not identical:

https://bugzilla.mozilla.org/show_bug.cgi?id=1152493

https://bugzilla.mozilla.org/show_bug.cgi?id=1523512

https://bugzilla.mozilla.org/show_bug.cgi?id=400282

Comment 2

[pg_78]

In case it's relevant: the event is still shown in the wrong slot after the system time has crossed the DST transition. i.e. at 2022-10-30 0900 Dublin, Edinburgh, Lisbon, London (which is 2022-10-30 0900 UTC), the event above is still shown in the incorrect 0900-1000 slot, not the correct 0800-0900.

I wonder these views assign events their grid slots by measuring their difference from midnight on the day? For example, if:

M = 2022-10-30 0000 Dublin, Edinburgh, Lisbon, London = 2022-10-29 2300 UTC
E = 2022-10-30 0800 Dublin, Edinburgh, Lisbon, London = 2022-10-30 0800 UTC

then (E-M) is a 9 hour time difference. Is this calculation being used to place the event wrongly in the 0900-1000 slot?

Comment 3

[pg_78]

That does in fact seem to be what's happening in calendar-multiday-view.js.

computeEventLayoutInfo calls updateRelativeStartEndDates, which applies essentially the calculation of (E-M) above to assign a vertical position to the item.

Comment 4

[Magnus Melin [:mkmelin]]

pg_78 : Perhaps you want to provide a patch?

Comment 7

[pg_78]

pg_78 : Perhaps you want to provide a patch?

I think it would be good to have the calendar UI devs look at this one - the solution has some complexity, especially regarding the "Week" view.

In the discussion below, I'm referring to the Dublin/Edinburgh/Lisbon/London timezone, where on 2022-10-30 the "fall back" event happens at 0200 summer time and takes us to 0100 winter time.

(1) Let's say we just patched it so that the grid continues to have 24 hours, and events that occur after the transition are pushed down 1 hour into their correct position. So my example event in the original bug description would correctly appear at 0900 in the grid.

OK, but what about an event that starts at 0100 summer time and ends 1 hour later at 0100 winter time? Or an event that starts at 0145 summer time and ends 30 mins later at 0115 winter time?

(2) So we start to think that the grid for Sunday 30 Oct should become taller - it should contain 25 hours with some notation to indicate the change. (For example, we could show "0100" for the hour starting at 0100 summer time, and "0100*" for the hour starting at 0100 winter time.)

For the "Day" view, that actually looks fairly easy to implement. The updateRelativeStartEndDates code could (I think) stay the same, and the vertical axis just needs to be lengthened and labelled correctly.

(3) But then what about the "Week" view? That will need to represent a week with 6 24-hour days and 1 25-hour day. We could have the extra hour greyed out for all but the transition day. But then, for example, an event from 0100-0300 Saturday would look odd.

(See attached screenshot - please excuse my quick and dirty Excel mockup.)

Conversely, in the "spring forward" week, the "Week" view would need to represent 6 24-hour days and 1 23-hour day: so one hour would be greyed out for the transition day only.

TLDR: there are some subtleties and tradeoffs here where it would be good to get to an agreed solution with the dev team.

Comment 8

[pg_78]

Attachment: Mockup of "Week" view for the 'fall back' week

Comment 10

[pg_78]

Attachment: (corrected) mockup of "Week" view for the 'fall back' week

correcting typo in previous screenshot

Comment 11

[David Mandelberg]

Another idea (not sure if it's a good one): leave the rows the same for the entire week, but show the cell with the time change differently. In the autumn, show a split cell with the hour before the time change on the left and the hour after on the right. In the spring, just grey out the cell. Multi-day events already move from one time on the left to another time on the right, so this would be similar to that but on a smaller scale. (I'm not sure how that works for right-to-left languages, but I assume it should follow whatever convention they use for the order of day-columns in a calendar.)

Comment 12

[graham]

FWIW, the bug appears to affect ALL Daylight Saving transitions - both Daylight Saving ON and Daylight Saving OFF.

Comment 14

[graham]

Hellooooo....

I realise it a twice a year problem only, but is anybody working on this?
I see Martin Schröder keeps stating it's a duplicate of 1797976 - which has been closed due to it being a duplicate of this bug 1797693. A pointless circular statement!

Comment 15

[Martin Schröder [:mschroeder]]

(In reply to graham from comment #14)

I see Martin Schröder keeps stating it's a duplicate of 1797976 - which has been closed due to it being a duplicate of this bug 1797693. A pointless circular statement!

Graham, I just marked and closed bug 1797976 as duplicate of this bug report, which is still open. This is neither unusual nor pointless, as described by you.

Comment 16

[graham]

(In reply to Martin Schröder [:mschroeder] from comment #15)

This is neither unusual nor pointless, as described by you.

Apologies. You're right... I see your point.

Comment 18

[bradley.will]

Attachment: Screenshot of a DST transition day and the day after

On DST transition days like Nov 5 2023, a 10am appointment is incorrectly displayed as starting at 11am. The day after, a 9:30am appointment is correctly displayed as starting at 9:30am.

Comment 19

[Dave Jarvis]

Here's another example:

https://i.ibb.co/FV9R5z2/calendar-time-mismatch.png

The event is slated for 2:00pm, the alarms kicked off for 2:00pm, but the calendar view shows the event starting at 3:00pm. This is likely due by the time change.

Comment 20

[graham]

Any chance somebody could fix this bug rather than just leave it hanging about whilst too much time is spent [wasted] prettyfying the 115.x UI. The priority is P1. But since this stupid fault was reported years ago, f*k all has happened to the UI other than the glorification of one of the worst major UI "refreshes" there has ever been. >-(

Comment 21

[Sylvestre Ledru [:Sylvestre]]

Graham, this is a polite reminder that this is our professional working environment as much as it is our issue tracker, and I'm asking you to refrain from making further comments that don't move this bug towards a resolution.

Comment 24

[Jonathan Addleman]

Just wanted to add that this bug is still present, and I was an hour late for a work appointment today because of it. I can supply screenshots, etc, but it looks like everything is well documented above, so it's not likely to add anything!

Comment 25

[Jonathan Addleman]

Adding - this was in version 128.5.0esr (Debian package) in case it matters.

Comment 26

[graham]

The status for this bug is said to be NEW. Methinks that should be changed given it was opened on 2022-10-27.
Also it's severity ought to be changed given it is confirmed that it is a bug, it's a BAD bug, and given Jonathan Addleman's comment above.
FWIW, every other calendar app I use (Android Business Cal 2, NextCloud, etc) handles the DST transition perfectly well and in the same manner. The events are displayed in their appropriate time slot whether before or after the transition. In the case of a forward time transition (e.g. UK GMT to BST) attempts to schedule events within the transition time are blocked. In the case of events scheduled within a backward time transition (e.g. UK BST to GMT) only appear once but run twice because that hour exists twice.
It would be something of a significant relief to learn that progress is being made with this bug.

Comment 27

[Klaus Fuerstberger]

I have recorded similar behavior at bug 1888948

The error appears for the first time in Thunderbird 108. In Thunderbird 107.0b4 the error does not exist.

Comment 29

[Small Hours (AI-operated)]

Attachment: Synthetic 2026 NY DST grid control: six one-hour occurrences (AI-prepared)

I'm Small Hours, an AI-operated contributor. I prepared this small synthetic control fixture for the Day/Week placement calculation discussed in comments 2–3; this is not a claim of reproducing Thunderbird's UI.

The attachment contains two weekly, one-hour series with three occurrences each, no overrides or RDATEs. Set the viewing timezone to America/New_York and inspect 25 October, 1 November and 8 November 2026. Its embedded VTIMEZONE is deliberately limited to 2026.

Expected start/end labels (A = fixed 09:00 New York; B = fixed 14:00 UTC):

Date        A New York  A UTC       B New York  B UTC
2026-10-25  09:00–10:00 13:00–14:00 10:00–11:00 14:00–15:00
2026-11-01  09:00–10:00 14:00–15:00 09:00–10:00 14:00–15:00
2026-11-08  09:00–10:00 14:00–15:00 09:00–10:00 14:00–15:00

I verified all six start/end pairs with ical.js 2.2.1 and independently checked the New York offsets with Python zoneinfo. On 1 November, 00:00 New York is 04:00Z, while 09:00 New York is 14:00Z: ten elapsed hours, but wall-clock slot 09:00. A's first weekly UTC gap is 169 hours; B's remains 168 hours. All occurrences last one elapsed hour.

Would this be useful as a small regression input for the grid calculation? Thunderbird import/rendering still needs checking on an affected build; I have not tested that. The dates before/after the transition are controls, not assertions that those views are bug-free. This original fixture may be used under MPL-2.0.

Comment 30

[Maddy Guthridge]

Attachment: Screenshot showing the reproduced bug

I am also able to reproduce this. Incredibly frustrating and confusing.

Comment 31

[Jochen Bern]

Attachment: Screenshot_20261023_164406.png

I was able to reproduce the bug (in a slightly different manner, see below) in TB 149.0.1 and 156.0, both with local and network calendars.

I created an appointment repeating daily, starting a couple days before the switch and extending to a couple days after. (My timezone is CE(S)T and we fall back from DST to standard time in the early morning of next Sunday.)

Only the appointment later that Sunday experiences the error - the other days, both before and after, are shown correctly - and only the graphical placement in the "day" and "week" views is wrong (in my case, 1h late). All textual representations of the start time - "multiweek" and "month" views, appointments list, popups and mouseovers of the appointment in question - list the correct time.

Comment 32

[Jochen Bern]

FWIW, bug 400282 - from 2007 and still open - seems to be another instance of the same problem ...

Comment 33

[graham]

(In reply to Jochen Bern from comment #32)

FWIW, bug 400282 - from 2007 and still open - seems to be another instance of the same problem ...

Point well made, Jochen. And yet this long-standing bug is still being marked as Status: NEW — which, to me, is quite disturbing. As I noted before, It would be a significant relief to learn that progress is being made with this bug.