Open Bug 1497463 Opened 6 years ago Updated 4 months ago

Lightning bug with older dates

Categories

(Calendar :: General, defect)

Lightning 6.2
x86_64
Windows 8.1
defect
Not set
major

Tracking

(Not tracked)

People

(Reporter: Spampot, Unassigned)

References

Details

(Whiteboard: [timezone][datetime-issue-6.2])

Attachments

(1 file, 1 obsolete file)

For some reason, Lightning can no longer handle dates before a certain limit correctly. In my case, the limit is 10/30/1995 ("30.10.1995" with German locale).
To reproduce: Go to "Events and Tasks\New event...", then

1.) Enter "29.10.1995" as the "Start" date
2.) Click into the "End" date edit field
Result (bug): The "Start" date is automatically changed to "28.10.1995", and the "End" date is set to "29.10.1995".

3.) Click back into the "Start" date edit field
Result (bug): The "End" date is automatically changed to "28.10.1995"

4.) Click into "End" date edit field again
Result: Nothing changes

5.) Click back into the "Start" date edit field
Result (bug): The "End" date is automatically changed to "27.10.1995"

6.) Click into "End" date edit field again
Result (bug): The "Start" date is automatically changed to "27.10.1995"

7.) Click back into the "Start" date edit field
Result (bug): Both dates are automatically changed to "28.10.1995", and an Alert message pops up saying "The end date you entered occurs before the start date". Afterwards, the "Start" date is reset to "27.10.1995" while the "End" date remains "28.10.1995".

None of the above bugs occurs if a start date of 30.10.1995 or later is entered in step 1. 

What I found out so far:
* Bug was first noticed with Thunderbird 60/Lightning 6.2
* Bug is fully reproducible with Thunderbird 60.2.1/Lightning 6.2.2.1 (both en-US and German versions)
* Bug also occurs on a "fresh" virtual machine with Windows 8.1 Professional 64-Bit (German language) with no further applications installed
* Bug also occurs with "fresh" Thunderbird install with a clean profile and no old/imported data
* Bug might be specific to Windows (I am using 8.1, see above), at least another user told he couldn't reproduce it on Linux Mint 19
Thanks for the report. I don't see this on current tip with Win 10, but haven't yet checked TB 60.

It reads like a timezone offset issue, can you answer a few questions to get a handle on it:

1. Is this a report for all-day events only or also for events with start and end time specified?
2. Does this occure if you have _any_ other addon disabled and TB restarted afterwards?
3. Is there any message in the error console (ctrl+shift+j) that is generated while reproducing the issue (if so, please post them)?
4. What is your Date and Time formatting setting (TB options -> Advanced -> Date and Time Formatting)?
5. If it is set to Regional setting locale, what is your timezone configuration for the Windows regional settings?
6. Does switching to Application locale change the behaviour for you?
7. What is you default timezone (TB options -> Calendar -> Timezone - if you haven't configured any, please do so and check whether the issue persits)?
8. Did you specify a event specific timezone (depends on your answer to question #1, obviously, since all-day event have no timezone)
Flags: needinfo?(Spampot)
I just tried again with TB 60.2.1 on a fresh Win 8.1 VM. It seems that the only dependency is the date itself: The bug ONLY occurs if a date before 10/30/1995 is entered. Any later dates (10/30/1995 and up) seem to work. The answers in detail:

1.) The bug occurs for BOTH all-day events and events with a start and end time. Only the details of how the dates are automatically changed are slightly different with all-day events.

2.) There are NO other add-ons installed, only Lightning itself. (It is a fresh TB install on a clean VM, so it only has what is included out of the box.)

3.) Immediately after TB startup, the following message is present:
---
While creating services from category 'profile-after-change', could not create service for entry 'calendar-backend-loader', contract ID 'service,@mozilla.org/calendar/backend-loader;1'
Use of Mutation Events is deprecated. Use MutationObserver instead.  calendar-widgets.xml:512:20
---
No further message appear while reproducing the bug.

4.) Thunderbird settings:
Tools\Options\Advanced\General\Date and Time Formatting
(x) Regional settings locale: German (Germany) [= default]

5.) Win 8.1 settings:
Timezone is "(UTC+01:00)Amsterdam, Berlin, ..."
Region is "Deutsch (Deutschland)" (German/Germany)

6.) When I change ...
Tools\Options\Advanced\General\Date and Time Formatting
(x) Application locale: English (United States)
... and go with a start date of "10/29/1995", then the exact same bug occurs.
(I also tried with the German version of TB, same bug here.)

7.) Tools\Options\Calendar\General\Timezone is set to "Europe/Berlin" [= default].
When I change it to "America/Detroit", the exact same bug still occurs.

8.) No, I didn't. But when I do, the bug still occurs.
Flags: needinfo?(Spampot)
I just had a chance to test on Windows 10 (64-bit): Same bug here, just like on Windows 8.1.
Ok, I can reproduce this in 6.2.x but I cannot on tip, which seems to be another bug (but maybe a workaround for 6.2.x), since the root cause for this behaviour still exist on tip.

The issue is related to a mismatch in calendar an icu [2] timezone definitions. Summertime switches where normalized in Europe starting with 1996 being the last Sunday in October resp. March. Before 1996, the automn switch in Germany took place at the last Sunday in September, but our timezone definition applies the current rules back until 1970 [1], while the icu definition is appropriate here [2] - see the unix timestamps in trans:intvector representin the rdates. So, for days between the last Sunday in September and October in 1981 to 1995 you will see this issue.

This got now more visible with the change of datetime formatting but applying the wrong timezone was an issue already before (e.g. bug 353381).

To get rid of it we would need to incoporate the complete history and not just the current timezone definition in our zones.json or get rid of managing our own timezone data and use what toolkit provides.

If we go the former way, we could also base our zones.json on the icu data in toolkit and make it created at build time instead of manually pulling the changes with our current scripts


[1] https://searchfox.org/comm-central/source/calendar/timezones/zones.json#2013
[2] https://searchfox.org/comm-central/source/mozilla/intl/tzdata/source/zoneinfo64.txt#2090
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [timezone]
Whiteboard: [timezone] → [timezone][datetime-issue-6.2]

I just experienced this bug over the past week, not sure if this information will offer any additional clues:

I'm using Windows 10 (64-bit) version 1803 and Thunderbird 60.4.0. My laptop's region is Germany but I'm currently in Turkey, where they stopped using Daylight Savings Time in 2016 (so currently two hours ahead of Germany).

I tried to create both a task and an event from a message. Regardless of whether I changed the start date, every time I opened the dropdown to set the end date, the date automatically changed to something-something-0002. I believe I was able to click on a date in the dropdown calendar, but it still reverted to some other date (not sure whether always the same date or different dates) in the year 0002. It was also not possible to type in the correct date, and then the warning about end date being before the start date appeared and could not be exited -- clicking on okay simply returned the warning on endless loop until I killed TB in the task manager.

(In reply to Brie from comment #6)

I just experienced this bug over the past week, not sure if this information
will offer any additional clues:

I'm using Windows 10 (64-bit) version 1803 and Thunderbird 60.4.0. My
laptop's region is Germany but I'm currently in Turkey, where they stopped
using Daylight Savings Time in 2016 (so currently two hours ahead of
Germany).

I tried to create both a task and an event from a message. Regardless of
whether I changed the start date, every time I opened the dropdown to set
the end date, the date automatically changed to something-something-0002. I
believe I was able to click on a date in the dropdown calendar, but it still
reverted to some other date (not sure whether always the same date or
different dates) in the year 0002. It was also not possible to type in the
correct date, and then the warning about end date being before the start
date appeared and could not be exited -- clicking on okay simply returned
the warning on endless loop until I killed TB in the task manager.

Your issue is bug 1503731. To work around it, set your timezone to Moscow instead of Istanbul.

I just realized I have this same issue - not sure when it started.
Here are some more information for whoever will address fix this.

Thunderbird 68.2.0 (64-bit) running on macOS Catalina Version 10.15

Creating a full day recurring event:
RRULE:FREQ=YEARLY;BYMONTH=12;BYMONTHDAY=3
DTSTART;VALUE=DATE:19601203

On the calendar, it shows up correctly on Dec-3.
But on the find-events window, the start and stop dates shows up as Dec-2.
On furthur inspection, Dec-1 is missing.
I.e., Thu Nov 30, 1960 is followed by Fri Dec 2, 1960.
And also there is two Dec 30 1960 (on Friday and Saturday).

In fact, the first of the month is always missing, and one day of month (varies) is doubled.
(I'll upload screenshot after I'm done.)
This error occurs until Dec 1970.
Starting from 1971, this missing 1st of the month error does not occur.

Note that -

  1. The calendar event shows up on correct date (Dec 3), but the find-event window (top part) shows start and end dates as Dec 2. The Dec 2 grid is correct, and Monday should have been marked as Dec 1st.
  2. Calendar is missing 1st of the month - Mon Nov 30 is followed by Tue Dec 2. In reality, in 1969, Monday should have been marked Dec 1.
  3. There is 2 dates marked as Dec 30th - on Tuesday and the following Wednesday. The following Thursday is marked as Dec 31. In reality, in 1969, Wed should be Dec 31, and Thu should be Jan 1st.
Attachment #9384880 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: