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 |
On 05/08/2009 03:52 PM, david-8uUts6sDVDvs2Lz0fTdYFQ at public.gmane.org wrote: > 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 conve= rts > 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-t= z-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 th= e > right timezone file under /usr/share/zoneinfo. Even if /etc/localtime i= s > checksum identical to the timezone file, it won't work right, because i= t > uses the name of the file being linked to to determine certain > information. If /etc/localtime is NOT a symbolic link to a timezone fil= e, > 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? > > =20 Sun invented symbolic links. Sun invented Java. --=20 Jerry Feldman <gaf-mNDKBlG2WHs at public.gmane.org> Boston Linux and Unix PGP key id: 537C5846 PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB CA3B 4607 4319 537C 5846
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |