I wasn't aware that anybody actually used this feature. Re-assigning to digital clock as that's the clock we should focus on most. And then we can take the stuff from there, if the maintainer and usability agree.

Also, in Plasma 4 we had a base class for "clock applets" (yes, seriously) so all the clocks had the same feature set in terms of calendar and configurability where also that context menu came from. This no more and most effort is spent in digital clock.

It makes a lot of sense to me that there would be shared functionality/code between all clocks (for example this one we're discussing) but if I trust anyone to make the correct technical decisions it's you KDE guys :)

Anyway if the digital clock maintainer finds it useful it would be great to see it ported to the fuzzy version! Just the number of times I alone use it would probably justify the implementation (unfortunately it's no so easy for me to code it myself).

BTW thanks for the fast replies and fixes (really, fastest bugfix ever on that other report I've opened) :D

The digital clock maintainer here.

I wasn't even really aware of that feature in plasma4 times. Adding it now...well, I dunno. I find it much faster to actually move my eyes to the corner where the clock is and just type it rather than fiddle with mouse, context menus, thinking which format I should choose and then pasting it. Date might be a bit different but very similar.

Can you state some usecases where this feature is really important?

It's not really important, just extremely convenient. Perhaps the time clipboarding is more useful on the fuzzy clock than on the digital clock but I found myself using the functionality on a frequent basis - be it working with spreadsheets or pasting a date/time stamp into a piece of text. The YYYY-MM-DD format is specially useful because it can be sorted naturally on spreadsheets or file-system folders and files, as is the YYYY-MM-DD HH:mm format.

I can't as a single person convince you that this is a necessary thing - but the fact that the KDE4 plasmoid would you let you choose between 10 or so date formats means the developer at the time thought it was very convenient, if not important. And I'm sure that if I'm posting this feature request here a lot of other people must also share my opinion but not know how to get in contact.

If it is the sort of thing that wouldn't take you long to code like #355191 I suggest you think about it. If it's something that requires a lot of time and refactoring, maybe it isn't worth it.

*** Bug 346306 has been marked as a duplicate of this bug. ***

*** Bug 358218 has been marked as a duplicate of this bug. ***

(In reply to Martin Klapetek from comment #3)
> I find it much faster to actually move my eyes to the
> corner where the clock is and just type it rather than fiddle with mouse,

But this is more error prone, and as originally stated - there were many different formats availble, some offering more information than what might be displayed in the clock (e.g. I have only time + but sometimes I need time + date in the clipboard....)

My most frequent usecases. Usual click flows for these in KDE 4 was right click on clock - copy date (there were a lot of formats, even chinese year and so on... but I used only two of them).

- I create a folder, and I want to have that folder having the current date in YYYY-MM-DD. 

- I create a journal entry in my journal (text file) - heading should be "hh:mm, weekday, DD(st/nd/rd/th) month, YEAR"

*** Bug 360469 has been marked as a duplicate of this bug. ***

Count me as another user who misses this functionality. I used to use it every couple of days to add dates to emails or add the date to a folder name. I found it quicker and less error prone that reading off the date and typing it in by hand. I was really frustrated when I found, for no apparent reason, this functionality had just disappeared.

+1
I was just about to file a bug report about this having just started using Plasma5 after being used to KDE4.
I really miss this feature - it may be faster for fast typists to just type the date, but for one finger users the mouse is much faster and less error prone.

This is still "NEEDSINFO WAITINGFORINFO", although 3 respondees provided information on their usecases.  What kind of more information is needed?

(In reply to cherenz from comment #12)
> This is still "NEEDSINFO WAITINGFORINFO", although 3 respondees provided
> information on their usecases.  What kind of more information is needed?

KDE developers are busy breaking things and adding shiny new features. Meanwhile you can write a patch implementing this feature yourself and try to get it merged. That's how open source works. Get used to it.

(In reply to Artem S. Tashkinov from comment #13)

> KDE developers are busy breaking things 
It was not broken in KDE4, so no comment...

> and adding shiny new features.
Surely it's more important to fix bugs than add shiny features.

> Meanwhile you can write a patch implementing this feature yourself and try
> to get it merged.
Whoa! So you are going to remove useful features at random and then ask users to re-implement them!

>That's how open source works. Get used to it.
Shame that you have this attitude - users are users - they are the people that you actually develop this stuff for, are they not?

Note that Artem is not a KDE developer and his opinions do not represent the opinions of us KDE developers.

The thing is that our manpower is limited and there are features like this one that we frankly did not consider as important as others. I'm not saying that having this feature would be a bad thing to have, which is why we would happily accept a patch if someone would actually implement it, it's just that it's unlikely for the core team to do this anytime soon. Also, I was actually looking into implementing this very feature recently but Artem's comment really drove away my motivation for that...

Created attachment 98279 [details]
KDE 3.5.10

(In reply to Kai Uwe Broulik from comment #15)
> The thing is that our manpower is limited and there are features like this
> one that we frankly did not consider as important as others.

Exactly. KDE developers code for _themselves_ and choose things to work on on their own. Their userbase concerns are not their own cencerns.

If what I'm saying is not true, we wouldn't have had two major fuck ups called KDE4 and KDE SC5. We wouldn't have had a situation when multiple applications from the past have no equivalents in KDE5. We wouldn't have had a situation when new KDE4/KDE SC5 application have far fewer features than their KDE3 counterparts.

> Also, I was actually looking into implementing this very feature recently but Artem's
> comment really drove away my motivation for that...

You see, you just prove my words all the freaking time. You're busy coding new shiny APIs no one cares about instead of making gradual changes while preserving old features.

Who exactly uses KDE SC5 on smartphones, tablets or Windows? Who cares how portable KDE is? People need to work for God's sake. You do _everything_ to break people's workflow and then you suddenly realize that people have stopped using your software. Run stats on KDE bugzilla and you'll suddenly realize people's activity as of recently has substantially decreased even though overall more people use Linux nowadays. Have you asked yourself why?

Do you realize that both KDE and Gnome have long stopped being the most popular DEs in Linux? Do you know what's number one right now? XFCE4 running GTK2 is. People are tired of your shit, sir. You do _not_ remove crucial features just because you believe that new APIs are better than the old ones. People do not care about APIs.

You do not remove xembed (systray) support and break dozens of apps, just because you think everyone should upgrade from xembed. You do not remove absolutely useful systray apps and replace them with UGLY unusable plasmoids which you cannot embed into systray at all, because you present information very sparsely.

Have a look at my task bar in KDE 3.5.10. Now tell me if I can do anything like that in KDE5.

1) It's fully transparent (it has an option for that) - do not tell me about unsupported KDE5 themes.
2) It has applications which don't have existing corresponding .desktop shortcuts.
3) It has KNetStats which show network activity in real time by blinking.
4) It has a weather applet.
5) KSensors (including _voltages_, _fans_ speed and temperatures).

You tell me to upgrade to KDE5 to have my workflow royally fucked? What for?

Don't get me started on the fact that KDE4/KDE5 are absolute resource hogs in comparison to KDE3 while _usually_ having less polish, working slower and having uglier UI out of the box.

It's not users who drive you away.
It's you who drive users away.

Dully noted. Now please go make something useful for the world.

(In reply to Kai Uwe Broulik from comment #15)
> Also, I was
> actually looking into implementing this very feature recently but Artem's
> comment really drove away my motivation for that...

Thats sad. And I did not want to start a flamewar on this. 
If I would have the time and skills to code this, I would do it - but since I lack both, I can only report bugs. I also did not intend to start a flamerwar...

Lets maybe put this as whishlist, and probably its a junior job. Maybe somebody will step forward...

There: https://phabricator.kde.org/D1350

Now that's what I call service!
Brilliant!
Works perfectly.
Which release is this likely to be included in?
I have patched 5.6.1 to test and am hoping our KDE/Plasma maintainer will accept it for our 5.6.2 package.
Many thanks :)

5.7 earliest because it contains new strings, which is not allowed in stable releases.

Why did it not get into 5.7 beta?

I'm sorry but we're missing API to refresh the time in the instance the menu is opened because our time engine is minute-aligned and thus the seconds in the menu would always be :00 or :59 or :01 and it was too late in the cycle to add that API.

Could it not be implemented with no seconds included for now?
This would be much better than nothing at all.

Will this be in 5.8.0?

Some progress made: 
https://phabricator.kde.org/D6183

Just a ping.  I am not on the latest Plasma - but on 5.8.7 (openSUSE Leap).  If this is fixed in newer versions then it should be closed?

I seem to be on 5.10.5-2 (Debian) and nothing changed effectively towards this.

I tried all of the default clocks right now (except the binary one) and right-clicking shows me no copy options.

I am now on 5.12.1 and this is still not available on right clicking the date.

Git commit ffa23acf440b0a162a9458f06622d2c98ed3f80c by Kai Uwe Broulik, on behalf of Bernhard Schiffner.
Committed on 11/04/2018 at 08:27.
Pushed by broulik into branch 'master'.

[Digital Clock] Allow copying current date and time to clipboard
FIXED-IN: 5.13.0

Differential Revision: https://phabricator.kde.org/D6183

M  +8    -0    applets/digital-clock/package/contents/ui/DigitalClock.qml
M  +3    -0    applets/digital-clock/package/contents/ui/main.qml
M  +2    -0    applets/digital-clock/plugin/CMakeLists.txt
A  +162  -0    applets/digital-clock/plugin/clipboardmenu.cpp     [License: GPL (v2/3)]
A  +59   -0    applets/digital-clock/plugin/clipboardmenu.h     [License: GPL (v2/3)]
M  +11   -0    applets/digital-clock/plugin/digitalclockplugin.cpp

https://commits.kde.org/plasma-workspace/ffa23acf440b0a162a9458f06622d2c98ed3f80c