Is exposing the server time a security risk?

The server time is of little use to an attacker, generally, as long as it is accurate. In fact, what is being revealed is not the current time (after all, barring relativistic physics, time is consistent everywhere) so much as the time skew. Note that, even if you do not explicitly reveal the time, there are often numerous ways to get the local server time anyway. For example, TLS up to version 1.2 embeds the current time in the handshake, web pages may show the last modified dates of dynamic pages, HTTP responses themselves may include the current time and date in response headers, etc.

Knowing the exact clock skew of a server is only a problem in very specific threat models:

• Clock skew can be used in attacks to deanonymize Tor hidden services.

• Poorly-written applications may use server time to generate secret values.

• Environmental conditions of the RTC may be revealed in contrived situations.

"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.

The only thing that could really expose a security risk is the high-precision timers and performance counters. These could be used to precisely time how long some cryptographic process takes on the server, and from there infer secret data.

Timing data to the milisecond or normal "tick" rate is unlikely to expose this.