W.B. Garvelink wrote:
For a good dissertation on what's wrong with util.Date, read up on
Stephen Colebourne's summary of it wrt to JSR-310 date/time API:
http://www.parleys.com/display/PARLEYS/Home#slide=1;title=JSR%20310%20-%20Date%20and%20Time%20API;talk=7602357
It's fairly comprehensive, and a lot more eloquent than I could
possibly explain it here.
I'll read that, thanks.
As for confusing, you've just proven my point:
http://java.sun.com/javase/6/docs/api/java/util/Date.html#Date(int,%20int,%20int)
(check out the range of the month number argument).
I agree that this is the badest month convention in the history.
I'll admit that's a bit mean.
Still, all that said, even if util.Date were immaculately designed and
extremely elegant in use, I would still have chosen to use a long
primitive in the FtpFile API. It's the simplest thing that could
possibly work, it's directly assignable from
java.io.File#lastModified()
I can always to new java.util.Date(java.io.File#lastModified()).
Is not directly assignable from a date that comes from database
(java.sql.Date).
and, on the API level, there's no
guarantee you ever need any of the value-add of a date class.
May be I want print a formatted date.
Also, as
Emmanuel pointed out, a long timestamp can be converted into any rich
date class (be it java.util, Joda, JSR-310 or any other) via a single
method call.
I'm not sure but I think that all those can convert in a single method
call from java.util.Date in their rich date class.
--
Andrea Francia
http://andreafrancia.blogspot.com/2008/07/colinux-linux-dentro-windows.html
