The user interface uses the short date format (e.g., Thu 28 Jan), which is fairly useless if one is trying to ascertain, e.g., how long a certificate has been valid or when it will expire. Reproducible: Always Steps to Reproduce: 1. Ensure at least one certificate has been imported 2. Open the certificate manager 3. Look at any dates, such as "Valid From" / "Valid Until" in the main pane, but also under Certificate Details, and possibly other places. Actual Results: Short dates are used, without the year. Expected Results: I expect a full, unambiguous date. Either a full date according to locale (but that's ambiguous thanks to Americans being weird like that), or perhaps better, an ISO-8601 date, which is what my Enigmail does.
Kleopatra uses QLocale::ShortFormat for dates. You should see the same date format in other KDE Applications and you can configure this in your system. Just try it out from the command line: LC_ALL=de_DE.UTF-8 kleopatra should show different formats then LC_ALL=C kleopatra I think this is the correct behavior respecting the users settings.
(In reply to Andre Heinecke from comment #1) > Kleopatra uses QLocale::ShortFormat for dates. Correct. Says so in the title of this bug report. > I think this is the correct behavior respecting the users settings. Which is why this bug report says the expected format should be either "a full date according to locale (but that's ambiguous thanks to Americans being weird like that), or perhaps better, an ISO-8601 date". I do not expect Kleopatra to offer options beyond what is provided by the system-wide locale settings, so using QLocale::LongFormat would be fine, but at the moment the interface is pretty useless since it does not allow you to unambiguously determine certificate validity dates due to using an inappropriate date format. Can you tell me how do *you* check your certificates' expiry dates in Kleopatra? And thank you so much for allowing the opportunity to respond before closing the ticket, by the way.
Hi, > (In reply to Andre Heinecke from comment #1) > > Kleopatra uses QLocale::ShortFormat for dates. > > Correct. Says so in the title of this bug report. As far as I understood you the original report was about: "(e.g., Thu 28 Jan)" So not including the Year and this is what you meant by ambiguous. Which I took down as "Bad configuration" > > I think this is the correct behavior respecting the users settings. > > Which is why this bug report says the expected format should be either "a > full date according to locale (but that's ambiguous thanks to Americans > being weird like that), or perhaps better, an ISO-8601 date". Why do you think a short date is ambiguous? It's the same date but in a different format. > I do not expect Kleopatra to offer options beyond what is provided by the > system-wide locale settings, so using QLocale::LongFormat would be fine, but > at the moment the interface is pretty useless since it does not allow you to > unambiguously determine certificate validity dates due to using an > inappropriate date format. > > Can you tell me how do *you* check your certificates' expiry dates in > Kleopatra? Again, I do not understand what you find so ambiguous about short dates. On my system the short format is (DD/MM/YYYY). While the Long format would include Weekday, and Month name. Including Weekday and Month I would find unnecessary information in Kleopatra and would help further clutter the interface. > And thank you so much for allowing the opportunity to respond before closing > the ticket, by the way. You can always respond (as you did) even to closed or resolved tickets. If one does not change the status directly tickets tend to "rot" in my experience.
(In reply to Andre Heinecke from comment #3) > As far as I understood you the original report was about: "(e.g., Thu 28 > Jan)" So not including the Year and this is what you meant by ambiguous. Correct. > Which I took down as "Bad configuration" Ok, this is what happened: before the last update to my system (I am running Tumbleweed, currently on 20160126), the default short date format for my locale (en_GB) was as mentioned above (Thu 28 Jan). It has since changed to 28/01/2016, which is what you are seeing, and so am I now on this machine (though not on my OpenSUSE 13.1 box, though at least I can actually change the defaults in System Configuration, as opposed to KDE5 (bug #340982 refers). So all in all, you're correct that this bug should be closed insofar as the default short date format now does display the year (thus resolving the ambiguity) and the long date format would be too unwieldy. > You can always respond (as you did) even to closed or resolved tickets. If > one does not change the status directly tickets tend to "rot" in my > experience. Yeah, I know. I leave mine open for a few days after last comment unless I'm in direct contact with the reporter. It does increase workload a bit though.