time change

[jc at trillian.mit.edu (John Chambers)]

John Abreau wrote:
| John Chambers <jc at trillian.mit.edu> writes:
| > Invariably it turns out to be time-zone problems caused by  the  fact
| > that  the java libraries use local time internally, and the code just
| > can't figure out how to adjust for DST  for  timestamps  coming  from
| > other  machines.
|
| That's a shame. I just recently started learning java, and I was happy
| to read that its internal clock type was a 64-bit millisecond clock
| based on the Unix epoch, which gave it a 3000-year timespan. Too bad
| they screwed up on the timezones.

Yeah; and actually it should be really easy for them to  solve  their
clock  problems.  Just ignore the silly part of the spec that says to
use local time for the internal representation.  Instead, define that
"internal"  time  in terms of a lower-level "OS" time that's the same
as the unix time.  The java library doesn't have to be built  at  the
lowest  (machine op-code) level; it can be defined in terms of things
even lower.  Then quietly write the routines in the  library  to  use
that  lower-level time rather than the local time.  No app could tell
the difference, and you'd keep your sanity while writing it.

I think the problem is that people think  they  have  to  follow  the
original  spec,  even  to  the extreme of the internal implementation
details.  It's mostly a case study of what  can  go  wrong  when  you
over-specify  something.  Java apps only need the functionality; they
don't need to have it done any specific way.

The rumors of some implementations that get the time right are likely
based  on libaries that ignore such over-specs and use the msec clock
as the basic time.