4

I have a client app running with JavaScript. and a server app running with Java. 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. Somewhere along the road, I want to calculate how much time has passed since the user performed that action until now - and I want to do this calculation in the server side.

My problem - the difference I'm getting between the current time of the server and the time the action was done is big, to big. probably because of time difference.

I want this calculation to be correct generally no matter where the client or server actually are. I know I'm supposed to use the GMT/UTC time but I just can't find the correct way of doing this.

UtkarshBhavsar
  • 249
  • 3
  • 23
iddqd
  • 1,225
  • 2
  • 16
  • 34
  • 2
    Trusting client clocks is a highly dubious practice. Can't you merely run a "something just happened" HTTP transaction, and have the *server* check it's trustable clock? – Pointy Nov 03 '13 at 15:35

2 Answers2

0

To get the UTC time one can use the (Gregorian) Calendar class:

Calendar cal = new GregorianCalendar();
System.out.println("UTC ms from the epoch: " + cal.getTimeInMillis());
naXa stands with Ukraine
  • 35,493
  • 19
  • 190
  • 259
Michael Besteck
  • 2,415
  • 18
  • 10
0

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

Community
  • 1
  • 1
Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154
  • In Java 8 and later, try using the new built-in java.time package. Joda-Time works as always, but java.time is its successor. – Basil Bourque Aug 10 '15 at 14:27