TimeZone in Java EE

Question

I want pass some Time value ( java.sql.Time) from back end to the front end in a Java EE project. For some historical reason, I parse the Time type to long type by call the method getTime(), which means I used long type to communicate between front end and back end. There comes the problem:

When I get long type time in the front end, I have to change the long type back to Time with the js method: new Date(long), but the value get from this method will diff from clients' timezone, which means different client in different timezone will see the result differently. This is absolutely not what I want. All the clients should see the same result, equals to the result in the back end.

Two ways to solve this:

1. Change the timezone of both front end and back end to UTC time, but java.sql.Time is timezone-independent, I have to change JVM timezone if I want to change the timezone of java.sql.Time. This is not a good way. Any other way to change the timezone?

2. Pass the timezone of back end to the front end. But change the timezone other than UTC in the front end is hard (may need some js lib).

Can anyone show me the best way to solve the problem?

Answer 1

Another way could be to:

1. Change the timezone of backend date to UTC. Use http://www.joda.org/joda-time/ - Joda API for the same. It is best on that. One of the best example is given here.

2. Pass the date to front end.

3. Convert the date in UTC format at front end and show it to end user.

Answer 2

tl;dr

Pass.

Duration                           // Represent a span-of-time unattached to the timeline.
.between(
    LocalTime.MIN ,                // 00:00:00.0
    LocalTime.of( 15 , 0 )         // 3 PM, with no date, and no time zone or offset-from-UTC.
) 
.toMilliseconds()                  // Get a count of elapsed milliseconds.

And parsing a count of milliseconds as a time-of-day without date, zone, or offset.

LocalTime lt = LocalTime.MIN.plus ( Duration.ofMilliseconds( milliseconds ) ) ;

java.time

You are using terrible date-time classes that were years ago supplanted by the modern java.time classes defined in JSR 310.

I want pass some Time value ( java.sql.Time)

That types has been replaced by the java.time.LocalTime class.

LocalTime lt = LocalTime.of( 15 , 0 ) ;  // 3 PM. 

I parse the Time type to long type by call the method getTime(), which means I used long type to communicate between front end and back end.

That is less that optimal. Better to communicate date-time values via text using standard ISO 8601 formats.

The java.time classes use the standard ISO 8601 formats by default when parsing/generating strings.

String output = lt.toString() ;

…and…

LocalTime lt = LocalTime.parse( "15:00" ) ;

But if we must continue with this hack of a count of milliseconds, we can.

Represent a span-of-time from the earliest time-of-day. This would be 00:00:00 for generic 24-hour days as represented in the LocalTime class. By the way, in some time zones on same dates, the day may begin at another time of day such as 01:00:00, but that is irrelevant here.

Duration d = Duration.between( LocalTime.MIN , lt ) ;
long milliseconds = d.toMillis() ;

And parsing that count of milliseconds back to a Duration and LocalTime.

Duration d = Duration.ofMillis( milliseconds ) ;
LocalTime lt = LocalTime.MIN.plus( d ) ;

Change the timezone of both front end and back end to UTC time

No need. The LocalTime class and Duration class both have no concept of time zone nor offset-from-UTC. So zone/offset is a non-issue.

I could make many points about your questions on the legacy classes. But there is really no reason to bother. Those classes are truly bloody awful, and should simply be abandoned.