As Pointy said, it is unwise to trust the clock of the client machine. And unnecessary in your case.
Your second sentence:
When the client preforms a certain action, I use Date.getTime() to log the time it was done, and send it back to the server.
…has it backwards. Server-side app should drive the logging, and send the facts to the client.
On the server side, in Java, use Joda-Time to capture the UTC time. Save that date-time either in a database's native date-time format or as an ISO 8601 formatted string. Storing milliseconds is not advisable as you need to know or record milliseconds from what epoch – most people assume Unix epoch but not all systems and software use that.
On the client side, send a string from the server to the client that describes the date-time in the user's local time zone. You need to be able to get the user's time zone of course. Most web browsers and web frameworks make that available to you.
Read on for an example of a server physically located in Seattle US with a user residing in Rome Italy.
Server-Side
Get the current date-time from a clock you can trust: your server machine’s clock.
// © 2013 Basil Bourque. This source code may be used freely forever by anyone taking full responsibility for doing so.
org.joda.time.DateTime now = new org.joda.time.DateTime(); // Using host system's clock and default time zone.
org.joda.time.DateTime utc = now.toDateTime( org.joda.time.DateTimeZone.UTC );
System.out.println( "Server's default local time in ISO 8601 format: " + now );
System.out.println( "UTC (Zulu) time zone: " + utc );
When run…
Server's default local time in ISO 8601 format: 2013-11-08T19:50:56.990-08:00
UTC (Zulu) time zone: 2013-11-09T03:50:56.990Z
Client-Side
When it comes time to display that date-time to the user, convert it to the user's local time zone.
Joda-Time converts to a String in ISO 8601 format by default. But you can use a formatter to create any string you want.
If you want to pass a java.util.Date object to your web framework, you may convert between Joda-Time and Date.
// © 2013 Basil Bourque. This source code may be used freely forever by anyone taking full responsibility for doing so.
org.joda.time.DateTimeZone romeTimeZone = org.joda.time.DateTimeZone.forID("Europe/Rome");
org.joda.time.DateTime userDateTime = utc.toDateTime( romeTimeZone );
System.out.println( "In User's time zone: " + userDateTime );
When run…
In User's time zone: 2013-11-09T04:50:56.990+01:00
About Joda-Time and related issues:
// Joda-Time - The popular alternative to Sun/Oracle's notoriously bad date, time, and calendar classes bundled with Java 7 and earlier.
// http://www.joda.org/joda-time/
// Joda-Time will become outmoded by the JSR 310 Date and Time API introduced in Java 8.
// JSR 310 was inspired by Joda-Time but is not directly based on it.
// http://jcp.org/en/jsr/detail?id=310
// By default, Joda-Time produces strings in the standard ISO 8601 format.
// https://en.wikipedia.org/wiki/ISO_8601
// About Daylight Saving Time (DST): https://en.wikipedia.org/wiki/Daylight_saving_time
// Time Zone list: http://joda-time.sourceforge.net/timezones.html
Tip: Time zone definitions change frequently and irrationally. Users’ memories change frequently and irrationally. If it is important in your business to factually record the user's perceived time, then do the work discussed above but also record the user's time zone identifier and the server's time as phrased in the user's time zone (what you would be sending to the user as their local time).