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.
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'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() and, on the API level, there's no guarantee you ever need any of the value-add of a date class. 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. Barend On Thu, Oct 9, 2008 at 2:15 PM, Andrea Francia <[EMAIL PROTECTED]> wrote: > W.B. Garvelink wrote: >> >> I wasn't involved in the design decision, but I would say a long is by >> far the simplest, smallest in memory and most flexible way of >> returning a time stamp. > > I doubt it is more flexible. > >> The util.date is bug-ridden, > > I doubt this java.util.Date is bug-ridden. > >> complicated, >> > > I don't think, maybe that Calendar it's complicated. >> >> inflexible (90% of the api is deprecated) > > The fact that 90% is deprecated does not mean that java.util.Date is > inflexible. >> >> and unnecessarily confusing >> > > Maybe. Where? >> >> with e.g. the zero-based months > > Zero based months are a convetion used by Calendar, not java.util.Date. >> >> and the odd interaction with Calendar, >> (default) Locale, and (default) TimeZone, > > All those are relevant for the Calendar API not the java.util.Date. > The java.util.Date simply wrap a long. >> >> all of which are irrelevant >> to time-stamping a resource. >> > > With a java.util.Date can simply formatted with String.format("%tX") it's > recognized as a date by many other library functions. > > -- > Andrea Francia > http://andreafrancia.blogspot.com/2008/07/colinux-linux-dentro-windows.html > >
