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
