"Servlet" sounds like you're already running a complex server there.
There's a lot of ways that protocols leak server time. For example, HTTP has a popular header field for creation/modification time, and dynamically generated data would always have the current system time, if used properly.
For TLS authentication reasons, you can even binary search to find an endpoint's date and time using expiring client certificates.
This is a necessary evil – if you're doing TLS, your server needs to have a notion of time to know what's a valid key / cert and what not. If that's the case, this will very likely be an NTP-coordinated time. So, you really can't tell anything about the server that an attacker wouldn't already know – there's really only one "correct" time.
If you're not doing TLS: leaking system time is probably not the first thing you should fix.
Regarding security: Not quite sure you should expose yet another servlet just for devices to figure out world time.
To explain more, this end-point will be used by mobile apps to enhance their security (to avoid cheating by adjusting the device date).
Red flag. You're depending on your client's unmodifiedness for security. Never do that. You simply can't trust anything happening on your user's devices. These are not your devices. They can simply hook up a debugger and modify notions of time in-memory of your process, no matter whether kept by the phone's OS or by your application.