No matter I choose "Short Date" or "Long Date" format in the Digital Clock settings, the year is in AD (Anno Domini) format. My locale is already set to ja_JP.utf8 (I verified it by running command "locale -a"), and I also made sure that I set all the formats to ja_JP in KDE System Settings. I expected that there should be an option to use the localized era year string, e.g. displaying "Heisei 29/01/01" instead of "2017/01/01". The following links are related to the localization / internationalization in KDE 4.x API which may be useful: https://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/kcalendarsystemjapanese_8cpp_source.html https://api.kde.org/pykde-4.7-api/kdecore/KLocalizedDate.html
Since this report you can now use a custom date string in the digital clock applet.
No, the custom date string still does NOT support localized era year string. From the time format documentation link in the applet [1], only "yy" (the year as two digit number) and "yyyy" (the year as four digit number) are supported. glibc supports eras very well, and you can use coreutils' `date` command to see the localized era string. Example 1 (Taiwan): 2020 in the ROC calendar [2] is "ROC 109", therefore ` LC_ALL=zh_TW.utf8 date +%EY` outputs "民國109年". Example 2 (Japan): 2020 in the Japanese era calendar scheme [3] is "Reiwa 2", therefore `LC_ALL=ja_JP.utf8 date +%EY` outputs "令和02年". I know KDE uses Qt so it uses Qt's formatDateTime() function, but is it technically possible to switch to glibc's format? Note 1: IIRC, XFCE's xfce4-datetime-plugin also uses glibc's format so localized era year string can be used. Note 2: The "%E" sequence in the format is not documented in `date`'s manual page. [1] https://doc.qt.io/qt-5/qml-qtqml-qt.html#formatDateTime-method [2] https://en.wikipedia.org/wiki/Republic_of_China_calendar [3] https://en.wikipedia.org/wiki/Japanese_era_name
This bug has NOT yet been fixed in 5.20.3 - please refer to the above comment.
*** This bug has been marked as a duplicate of bug 348071 ***
*** This bug has been marked as a duplicate of bug 340982 ***
Bug 340982 seems to be a different issue... I hope it's OK to close my own bug as "UPSTREAM" since the custom date and time format in Plasma is based on Qt's QDate and QTime formats.