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.
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.
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.
It would become a nested loop, though it may well be that it's still not noticeable. I'll play around with it.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/354