• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

To Peter - Best practices for working with dates in Java

 
Ranch Hand
Posts: 1211
Mac IntelliJ IDE
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Peter,

It is great to have you on this forum.
Would you recommend any best practices for using dates and times in Java?

Thanks
Sonny
 
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here is a good article
http://www.onjava.com/pub/a/onjava/2003/06/05/java_calendar.html
 
Ranch Hand
Posts: 3178
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Oh Sonny's question just make me have a look at the TOC of the book... I don't see any chapter seems to discuss about the utility classes...

Peter, did u mention utility classes in some chapters? Of course, collections are in utility package, but what about date and time classes?

Or am i missing sthing?
 
Ranch Hand
Posts: 445
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Working with dates is a real pain in Java.After introducing so many fancy things such as Autoboxing & Generics, Sun should have made the Date class more simpler to use.
 
Pradeep bhatt
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Sun should have made the Date class more simpler to use.



They should rewrite it completely.
 
Ranch Hand
Posts: 192
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
yes me too feel the same.
Generally we use a set of utilities for date processing and use it all over the project. Ease of use of Date classes is missing in Java.
 
Sonny Gill
Ranch Hand
Posts: 1211
Mac IntelliJ IDE
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Pradeep Bhat:
Here is a good article



Thanks Pradeep. I remember running into that article a while ago.
But it would be good to hear what Peter has to say on this topic.

BTW, Thomas Paul and Jim Yingst discuss 'comparing dates' here -
https://coderanch.com/t/35080/Programming/calculate-number-days-between-two

cheers.
 
author
Posts: 46
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sonny asks about using dates/times in Java.

I can only echo the perceptive words of Vedha Pitkar, who indicates that it is a challenging
and indeed vexing area. It is not only Java - this area is challenging in all programming
languages. It turns out that there are enough things about dates and times that are
non-obvious or even counter-intuitive, that it presents some real challenges both for
implementors and for application programmers.

The first Java date/time implementation was coded in something of a rush by James Gosling,
and he got all caught up in the minutiae of leap seconds and royal observatories. He
followed prevailing practice of the early 90's and TRIED TO SAVE SPACE BY NOT USING THE
FULL FOUR DIGIT YEAR!! Arghhh! In the Date package, years are stored as (year-1900), so
1999 would be 99 (which kinda seems OK), but 2004 is 104 (which really is NOT ok). You
can see all this in the comments if you read the source code. Just java tells you where
to find the source and how to unpack it, and how to look at it - see page 62.
There are a LOT of other problems with Date too, but lets not get into that now.

People pretty soon realized this date stuff was the most tremendous screw-up, but then Sun was
caught in the bind of backwards compatibility. Unlike Microsoft, which has the "API of the
Month Club" and jerks around its development community like crazy (right now MS is trying
to push everyone onto the .Net bandwagon, with noticeable lack of success. Programmers
are asking, quite rightly "why should I learn all that .net stuff when you are going to yank
it all around again with Longhorn (next release of Windows)?").

Anyway, Sun doesn't do that - Sun has made huge efforts to keep Java backwards compatible,
and only a little while ago one of the compiler development team engineers was telling me
about an old Java binary he had laying around. He looked at the date on it, and it was from 1995!
Before even the FCS of Java! He tried running it, and to his surprise (with all the changes in the
JVM, the class file format, the libraries and so on) it Just Ran Perfectly!

So for reasons of backward compatibility, and keeping existing code running, Sun did not
rip out and throw away Date. Instead most of the class was deprecated, and some new classes
Calendar and friends were adopted. I have got 5 pages on Calendar utilities starting at
page 483 in Just Java.

The Calendar classes were written by IBM, but not for Java. They were original developed for the
ill-fated Pink project from the Taligent joint venture between Apple and IBM. In one of the
great "Might Have Beens" of history, Apple and IBM had got together in the early 90's to
develop an OS environment/language that was positioned squarely where Java is. They should
have got there first! They didn't! Sun did, and the results are what we know and love today.

So IBM had tons of date processing code in nominally better shape than Sun's Date class,
so they did a quick re-write into Java , presto-chango! Date problems all fixed!? Not really.
IBM's new code sucked almost as badly as the original Date class. The problem was and is
that Calendar is over-generalized. That allows you to set up a e.g. Nepalese calendar, but
adds tremendous complexity to the case that 99% of programmers have to use, the
Gregorian calendar.

Well, I could yammer on for a long while about the errors of over-generalization, but
I will probably overstay my welcome and I don't want to do that. Let me just say that
I do not mean to denigrate anyone's work, just point out that programming is a very
human endeavor, and therefore subject to all the weaknesses, defects and frailities of
the human condition. Having taken 2 whacks at it now, and having a MUCH larger code
base using Calendar at this point we are stuck with what we have, and just have to make
the best of it.

Best practices for date? Follow these three rules:
1. Keep the code as simple as possible, and do not over-generalize.
2. Comment carefully to say what your design is, and what you intend
3. Translate all date-times into a fixed calendar and GMT directly on input.
Keep all date-times in that internal format at all times
Process all date-times in that internal format at all times.
When you are about to output a date/time for display, make the appropriate
conversion to local calendar/timezone at that specific point.

Cheers,

Peter
 
Ranch Hand
Posts: 808
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Peter -

Thanks for the highly entertaining history of date classes and such. I'm working on a time/date-stamp algorithm in C for an embedded system and I can tell you it's a pain in the lower-regions, but not as bad as Java's Date class.
 
Sonny Gill
Ranch Hand
Posts: 1211
Mac IntelliJ IDE
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Peter,

That was interesting history on java dates.
Thanks for the tips.

One more question -

From Javadocs for Timestamp -


Due to the differences between the Timestamp class and the java.util.Date class mentioned above, it is recommended that code not view Timestamp values generically as an instance of java.util.Date. The inheritance relationship between Timestamp and java.util.Date really denotes implementation inheritance, and not type inheritance.


http://java.sun.com/j2se/1.5.0/docs/api/index.html

Would it be safe to ignore that warning, if I am only interested in the date, hours and minutes part of the Timestamp?
i.e. If I am not concerned with microsecond precision, Can I write my 'Date' utility classes using java.util.Date, and safely pass java.sql.Date, Time or Timestamp objects?

cheers,
Sonny.
 
Peter van der Linden
author
Posts: 46
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Sonny,

> Would it be safe to ignore that warning, if I am only interested in the
> date, hours and minutes part of the Timestamp?

Good work on getting a second opinion on this subtle area!
And Especially Good Work on reading the API, and finding a note of caution there,
and asking about the practical impact of that! That kind of attention to detail is
exactly the sort of skill that really good programmers show!

If I were in your position, I think I would heed the warning and NOT use the
superclass of Date to represent java.sql.Date, java.sql.Timestamp and java.sql.Time.
One of the things you are sure to be doing is comparing for equality, and the
API docs explain how that is lacking. [This seems like a really badly put together
part of the API, but we knew that already].

I don't know what the right approach is -- that will depend on your needs. Can you
simplify by just using one of the three classes java.sql.Date, java.sql.Timestamp and java.sql.Time
and ignore the others?

Maybe some other readers have some ideas, or perhaps an enquiry in the database
forum would come up with details of how other have tackled this.

Cheers, Good question!

Peter
 
Sonny Gill
Ranch Hand
Posts: 1211
Mac IntelliJ IDE
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks, Peter. The encouragement you gave is much appreciated.

Basically, my question was in regards to having a class with convenience methods like



to make code more readable. It seems ok to pass this method any Date subclass on the surface, I was wondering if there are any hidden pitfalls there.

I think I will follow your advice, and perhaps have overloaded methods that accept the different subclasses to be safe.

Thanks again.

Cheers
Sonny
 
Vedhas Pitkar
Ranch Hand
Posts: 445
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Peter for letting us know some very useful information!
 
reply
    Bookmark Topic Watch Topic
  • New Topic