Uh no the date is correct. Indeed those are the only files with wrong date in the filesystem. I know that because I run
find ./ -type f -printf "\n%TY%Tm%Td %TT %p \n " | grep [0-9] | sort -r -k 1,1 -k 1,2
But it is strange that a JSON file generated by Nextcloud or the app has the year 2027. I can’t even imagine Nextcloud or the app making up the date. I would always think it came from the system date. I think e.g. PHP would always use the system date. But maybe there is a bug in the software.
The Music app sets the time-to-live for this cached file as 5 years. I believe that Nextcloud somehow implements the time-to-live feature by setting the timestamp to the future.
So the point is, whenever Nextcloud caches anything, the timestamp will be in the future. But it’s just easy to spot on this particular file because the TTL is so long.
What will happen if you manually touch the file, is that 1 hour after the touching the cached file will be deleted by Nextcloud. Then, the next time you open the Music app, the file will be recreated, again with the timestamp 5 years in the future.
Edit: Or actually, it might not be recreated yet on the Music app reload because your browser may still hold the cached version of the file. But if you use another browser or clear your browser cache, then the file will be recreated.
I ran into this problem when I tried to restore a nextcloud snap. The restore crashes since it cannot unpack an archive with a future time stamp. Is this a known issue with using nextcloud in a snap? Does anyone have a work arround?
I have no experience or knowledge on the Nextcloud snap but maybe you would want to report this for Issues · nextcloud-snap/nextcloud-snap · GitHub. Using future timestamps is normal behavior of Nextcloud so obviously also Nextcloud snap needs to be able to live with those.