Why Java's Time related classes are so confusing and error-prone?

[www]

Hi,

I found that Java's time related classes are so hard to use. For example:

GregorianCalendar cal = new GregorianCalendar();
cal.setTimeInMillis(0); //set cal at January 1st 00:00:00, 1970

To TRUELY understand the above code and use it correctly, I need to know
that BY DEFAULT, GregorianCalendar set its time zone from my computer
location. Since I am in the east coast of US, the time zone of the
object cal is set as East Daylight Saving Time. So for another computer
located in California, running the above two lines of code, cal time is
different. Ok, I try to remember that.

Now:

Date date = new Date();
date.setTime(long time); //takes a long argument

By default, date time zone is UTC (Universal time, greenwich time -- GMT).

Am I using them in-correctly or they are really error-prone?

Thank you for your feedbacks.

 

[Stefan Ram]

Am I using them in-correctly or they are really error-prone?

Although one might say »Then, read the manual of
those classes, first«, you are right, that they often
do not fit.

That might be the reason for the third generation (Joda):

http://jcp.org/en/jsr/detail?id=310

I have also written date and time classes myself and
prefer to use explicit specification of the time zone,
whenever appropriate.

To add 10 minutes to the current time using my classes:

public class Main
{
public static void main( java.lang.String[] args )
{
final de.dclj.ram.system.gregorian.DefaultJavaInstant t =
new de.dclj.ram.system.gregorian.DefaultJavaInstant();

de.dclj.ram.routine.java.util.Instant.setToWallClock( t );

java.lang.System.out.println
( new de.dclj.ram.notation.iso8601.Instant( t ));

t.add( 1. / 24 / 60 * 10 );

java.lang.System.out.println
( new de.dclj.ram.notation.iso8601.Instant( t )); }

}

2007-06-20T18:25:33+02:00
2007-06-20T18:35:33+02:00

Here the time zone is part of the default toString()-result,
so that one becomes aware of it. IIRC, the zone »+02:00« is
stamped on the instant by »setToWallClock«.

To get a time difference between two dates, one also usually
specifies the zone explicitly, when using my classes:

public class Main
{ public static void main( final java.lang.String[] args )
throws java.text.ParseException
{
final double now =
new de.dclj.ram.notation.iso8601.Instant
( "2005-05-22T14:12:23+02:00" ).doubleValue();

final double then =
new de.dclj.ram.notation.iso8601.Instant
( "1970-01-01T00:00:00+01:00" ).doubleValue();

final double diff = now - then;

final double ms = 1. / 24 / 60 / 60 / 1000;

java.lang.System.out.println( diff / ms ); }}

1.11676754299999E12

Responding to criticism, I plan as a next step to
convert time differences and times to high precision
arithmetics, so that the result is intended to become

1.116767543E12

 

[Eric Sosman]

www wrote On 07/02/07 15:12,:

Hi,

I found that Java's time related classes are so hard to use. For example:

GregorianCalendar cal = new GregorianCalendar();
cal.setTimeInMillis(0); //set cal at January 1st 00:00:00, 1970

To TRUELY understand the above code and use it correctly, I need to know
that BY DEFAULT, GregorianCalendar set its time zone from my computer
location. Since I am in the east coast of US, the time zone of the
object cal is set as East Daylight Saving Time. So for another computer
located in California, running the above two lines of code, cal time is
different. Ok, I try to remember that.

Now:

Date date = new Date();
date.setTime(long time); //takes a long argument

By default, date time zone is UTC (Universal time, greenwich time -- GMT).

Am I using them in-correctly or they are really error-prone?

Thank you for your feedbacks.

Java's time classes *are* confusing, but at least part
of the blame lies not with Java but with the confusing ways
we humans measure the passage of time. Leap days, leap
seconds, lunar calendars, time zones, time zone adjustments
made according to local political whim, ...

However, I think you're adding to your own confusion by
mixing up the moment a Calendar represents with way it looks
when printed out. Part of a Calendar's job is to figure out
all those time zone adjustments and stuff, so that it can
produce a printed representation that matches local custom.
When you set a Calendar to time zero, you have set it to

1970-01-01 00:00:00.000 UTC
1969-12-31 19:00:00.000 EST
1969-12-31 16:00:00.000 PST
1970-01-01 01:00:00.000 CET

.... and many, many more representations. They are all the
same moment, just printed out differently. And this makes
perfect sense: If Greenwich Observatory broadcasts a radio
bleep to signal the start of the new year, you will miss
hearing it if you don't turn on your radio until midnight
Eastern time. To pick up the bleep, you must turn on your
radio while it's still December in EST -- and that's exactly
what Calendar is telling you.

Keep the notions of "actual time" and "represented time"
separated, and I think you'll have an easier, er, time.

 

[Roedy Green]

I found that Java's time related classes are so hard to use

You should have seen Date. Calendar is poetry by comparison, though I
agree it is a mess.

I wrote BigDate in self defence. See
http://mindprod.com/products1.html#BIGDATE

There are many pitfalls. See http://mindprod.com/jgloss/calendar.html
and follow the links.

 

[Twisted]

You should have seen Date. Calendar is poetry by comparison, though I
agree it is a mess.

And Java 7 is proposed to include a replacement for Calendar in turn.
Third try's the charm?