Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
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.
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |