Bug 466899

Summary: Don't require that input time's time format match the local time zone's time format
Product: [Plasma] krunner Reporter: Nate Graham <nate>
Component: datetimeAssignee: Natalie Clarius <natalie_clarius>
Status: ASSIGNED ---    
Severity: wishlist CC: alexander.lohnau, natalie_clarius
Priority: NOR Keywords: usability
Version First Reported In: master   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Nate Graham 2023-03-05 16:58:31 UTC 
All the recently added time zone conversion stuff is awesome! But I find that unfortunately it still doesn't help me as much as would be ideal for the simplest use case. Imagine someone sends a message like this:

"how about tuesday @ ~19:30 cet?"

I'd like to be able copy the time "19:30 cet" and paste it into KRunner to have it tell me what time that is in my local time zone. But it doesn't do that because the 24-hour input time format doesn't match my local time zone's 12-hour AM/PM time format. So I still need to manually convert "19:30" to "7:30 PM" and enter that into KRunner; only then will it tell me the time in my local time zone.
Comment 1 Natalie Clarius 2023-03-05 22:54:35 UTC 
I had the same thought, but haven't found a satisfactory solution.

This is all the valid short time formats (ignoring dates) across locales:

> 'Kl'. H.mm
> AP 'ga' h:mm
> AP h.mm
> AP h:mm
> APh:mm
> B H:mm
> H.mm
> H:m
> H:mm
> H:mm 'hodź'.
> H:mm 'ч'.
> HH 'h' mm
> HH.mm
> HH:mm
> HH:mm:ss
> h:mm AP
> hh:mm AP
> ཆུ་ཚོད་ h སྐར་མ་ mm AP

Note that these don't uniquely map to the possible strings, e.g. "h" means with or without leading zero and "AP" is the A.M./P.M. affix to be spelled out. See https://doc.qt.io/qt-6/qtime.html#toString.

Initially I tried with a regex, but that became monstrous rather quickly and only introduces bugs like we already had in the night color KCM so I don't think that's a viable alternative.

Iterating through all locales would be possible but costly performance-wise, and would introduce problems with multiple valid interpretations of dates (d/m/y vs m/d/y format).

We could settle on a few selected formats, like C, en_US and the system locale, and hope that that covers most use cases.
Comment 2 Nate Graham 2023-03-05 23:01:37 UTC 
Depending on how poor the performance of iterating through all locales is, it might not even be noticeable. If that's the case, I think it could be the winning solution.
Comment 3 Natalie Clarius 2023-03-05 23:08:02 UTC 
It would become a nested loop, though it may well be that it's still not noticeable. I'll play around with it.
Comment 4 Bug Janitor Service 2023-03-06 02:04:36 UTC 
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/354