Bug 504755 - Hovering over calendar day shows wrong date
Summary: Hovering over calendar day shows wrong date
Status: RESOLVED INTENTIONAL
Alias: None
Product: plasmashell
Classification: Plasma
Component: Digital Clock widget (other bugs)
Version First Reported In: 6.3.5
Platform: NixOS Linux
: NOR minor
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-05-25 03:10 UTC by Christopher Iman
Modified: 2025-05-30 06:23 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments
Shows a calendar day being hovered over and the date in the hover pop up not matching the day being hovered over (198.98 KB, image/png)
2025-05-25 03:10 UTC, Christopher Iman
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Iman 2025-05-25 03:10:32 UTC
Created attachment 181721 [details]
Shows a calendar day being hovered over and the date in the hover pop up not matching the day being hovered over

When hovering over the a calendar day with the mouse the date is off by like 13 days for me.

Also I am unsure if this should be on the Calendar widget itself or on the Digital Clock widget or on libplasma components since I read the component description on this section and have no idea if this is a bug with the calendar grid itself or if it is a separate thing that is only related to the calendar grid or if it should be for the digital clock widget.
Comment 1 cwo 2025-05-25 10:06:14 UTC
Thank you for the report! 

This is not a bug; the calendar does not show a tooltip for the regular date.

You have the Alternate Calendar plugin enabled and set to the Julian calendar, the calendar format used in the West before the Gregorian calendar, and still used in some contexts like Orthodox Christianity: https://en.wikipedia.org/wiki/Julian_calendar. It does not follow the Earth's rotation around the sun as closely, and is therefore diverging from the Gregorian calendar over time, more precisely by 13 days in 2025.

The Calendar does show a tooltip for the Alternate Calendar, as the months do not line up, so it can be helpful for people who regularly need to know the current date in an alternate calendar format to see the full date including the name of the month.

If you do not regularly require to know the current date in the Julian (or Chinese Lunar, or Hebrew etc.) calendar, I recommend turning the plugin off (we don't ship it enabled by default).
Comment 2 Christopher Iman 2025-05-25 17:26:24 UTC
(In reply to cwo from comment #1)
> Thank you for the report! 
> 
> This is not a bug; the calendar does not show a tooltip for the regular date.
> 
> You have the Alternate Calendar plugin enabled and set to the Julian
> calendar, the calendar format used in the West before the Gregorian
> calendar, and still used in some contexts like Orthodox Christianity:
> https://en.wikipedia.org/wiki/Julian_calendar. It does not follow the
> Earth's rotation around the sun as closely, and is therefore diverging from
> the Gregorian calendar over time, more precisely by 13 days in 2025.
> 
> The Calendar does show a tooltip for the Alternate Calendar, as the months
> do not line up, so it can be helpful for people who regularly need to know
> the current date in an alternate calendar format to see the full date
> including the name of the month.
> 
> If you do not regularly require to know the current date in the Julian (or
> Chinese Lunar, or Hebrew etc.) calendar, I recommend turning the plugin off
> (we don't ship it enabled by default).

Ah okay thanks for pointing that out, I think I enabled it because I was curious what it was and at the time just saw it added an additional setting page and not much else so I didn't think that it would have changed anything.
Comment 3 cwo 2025-05-25 17:59:07 UTC
(In reply to Christopher Iman from comment #2)
> Ah okay thanks for pointing that out, I think I enabled it because I was
> curious what it was and at the time just saw it added an additional setting
> page and not much else so I didn't think that it would have changed anything.

Yes, we're not explaining what they do and some calendar plugins are not quite self-explanatory.

We already have some strings for that, they're just not shown in the UI. Exposing them isn't hard, but the ones we have aren't really good at explaining what they do either, and for Plasma 6.4 we can't change the strings anymore as the translators are already working on them, so it's too late to get good ones fir this release.

I've wondered before whether there should be a separate "No alternate calendar" option that's selected by default in the Alternate Calendar list – Julian Calendar as the default is somewhat arbitrary. But if you don't want any alternate calendars, it's probably better to disable the plugin completely and not spend resources on loading it, and having one selected as default helps users see more quickly what the plugin does.

If you have strong feelings about this, feel free to open feature request for this, but I think a better explanation right where you enable it should suffice.
Comment 4 Christopher Iman 2025-05-25 22:30:18 UTC
(In reply to cwo from comment #3)
> (In reply to Christopher Iman from comment #2)
> > Ah okay thanks for pointing that out, I think I enabled it because I was
> > curious what it was and at the time just saw it added an additional setting
> > page and not much else so I didn't think that it would have changed anything.
> 
> Yes, we're not explaining what they do and some calendar plugins are not
> quite self-explanatory.
> 
> We already have some strings for that, they're just not shown in the UI.
> Exposing them isn't hard, but the ones we have aren't really good at
> explaining what they do either, and for Plasma 6.4 we can't change the
> strings anymore as the translators are already working on them, so it's too
> late to get good ones fir this release.
> 
> I've wondered before whether there should be a separate "No alternate
> calendar" option that's selected by default in the Alternate Calendar list –
> Julian Calendar as the default is somewhat arbitrary. But if you don't want
> any alternate calendars, it's probably better to disable the plugin
> completely and not spend resources on loading it, and having one selected as
> default helps users see more quickly what the plugin does.
> 
> If you have strong feelings about this, feel free to open feature request
> for this, but I think a better explanation right where you enable it should
> suffice.

Yeah if anything just a better explanation for what it does would be fine in my opinion since I probably wouldn't have enabled it and forgot about it if I knew what it did to begin with
Comment 5 Bug Janitor Service 2025-05-28 10:47:15 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5533
Comment 6 cwo 2025-05-30 06:23:20 UTC
Git commit a11c6765f14f4592c054d49771431d669c72ef53 by Christoph Wolk.
Committed on 30/05/2025 at 05:37.
Pushed by cwo into branch 'master'.

applets/digital-clock: use ListView for plugins

The calendar plugin names are not completely self-explanatory; if you
don't already know that "Alternate Calendar" shows the date in an
alternate calendar format or that "Calendar Events" is for showing
events from an Akonadi calendar, it might not be apparent from the
(otherwise sensible) names. The plugins already have description fields
in their metadata  (though the current strings are not quite optimal, as
they weren't exposed in the UI) and even icons, but we don't use them.

Instead, use a ListView and (Check)IconTitleSubtitle to display nice-
looking list entries for the plugins that can have descriptive labels
associated with them.

M  +1    -1    appiumtests/applets/digitalclocktest.py
M  +40   -39   applets/digital-clock/package/contents/ui/configCalendar.qml

https://invent.kde.org/plasma/plasma-workspace/-/commit/a11c6765f14f4592c054d49771431d669c72ef53