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 |
I posted this problem in Sun's support forum and didn't get an answer there, but I finally found the solution. But the solution is so bat-s**t crazy, I just had to post it here. I've used Calendar, Date, and System.currentTimeMillis(). It all converts to one hour earlier than it should. If it's now 8:54 EST (12:54 GMT), and the time from all of those translate to 7:54am. Googling around I couldn't see a fix, but I do see clear indications that the problem is a time zone one. Here's the answer, which I found at http://www.velocityreviews.com/forums/t679924-p4-diagnose-why-pacific-tz-has-wrong-startstop-dates-for-dst-with-jdk16-on-ubuntu.html Sun's Java under Linux needs /etc/localtime to be a symbolic link to the right timezone file under /usr/share/zoneinfo. Even if /etc/localtime is checksum identical to the timezone file, it won't work right, because it uses the name of the file being linked to to determine certain information. If /etc/localtime is NOT a symbolic link to a timezone file, it uses the name of the first timezone file it finds with identical contents to /etc/localtime. I am not impressed with this design. Who came up with that?
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |