Diagnose why Pacific TZ has wrong start/stop dates for DST, with JDK1.6 on Ubuntu

D

david.karr

Here in Seattle, on April 14, we're in daylight savings time. I've
noticed since DST started that log files created by Java applications
on my Ubuntu box are an hour behind. I figured it had something to do
with daylight savings time. Non-Java applications do not display this
symptom.

If it matters, here's the output of "java -version":

java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing)

I wrote a small test application that prints out relevant information
about daylight savings time. I'll attach the test code, but the
output it produces follows this. You'll see that as of today, it
thinks DST is not in effect. It also shows that it thinks DST starts
on April 26, and ends on October 25, which is not correct.

I filed a Ubuntu bug report for this, but I'd like to get some
feedback from "this side of the house" to see why this might be
happening.

date[Mon Apr 13 13:04:01 PST 2009] zonename[Pacific Standard Time]
dstSavings[3600000] usesDST[true] inDST[false] rawOffset[-28800000]
offset[-28800000]
date[Mon Apr 13 13:04:01 PST 2009] inDST[false]
date[Wed May 13 13:04:01 PDT 2009] inDST[true]
date[Sat Jun 13 13:04:01 PDT 2009] inDST[true]
date[Mon Jul 13 13:04:01 PDT 2009] inDST[true]
date[Thu Aug 13 13:04:01 PDT 2009] inDST[true]
date[Sun Sep 13 13:04:01 PDT 2009] inDST[true]
date[Tue Oct 13 13:04:01 PDT 2009] inDST[true]
date[Fri Nov 13 13:04:01 PST 2009] inDST[false]
date[Sun Dec 13 13:04:01 PST 2009] inDST[false]
date[Wed Jan 13 13:04:01 PST 2010] inDST[false]
date[Sat Feb 13 13:04:01 PST 2010] inDST[false]
date[Sat Mar 13 13:04:01 PST 2010] inDST[false]
date[Sun Apr 26 00:00:00 PST 2009] inDST[false]
date[Mon Apr 27 00:00:00 PDT 2009] inDST[true]
date[Sun Oct 25 00:00:00 PDT 2009] inDST[true]
date[Mon Oct 26 00:00:00 PST 2009] inDST[false]
 
J

John B. Matthews

"david.karr said:
Here in Seattle, on April 14, we're in daylight savings time. I've
noticed since DST started that log files created by Java applications
on my Ubuntu box are an hour behind. I figured it had something to do
with daylight savings time. Non-Java applications do not display this
symptom.

If it matters, here's the output of "java -version":

java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing)

I wrote a small test application that prints out relevant information
about daylight savings time. I'll attach the test code, but the
output it produces follows this. You'll see that as of today, it
thinks DST is not in effect. It also shows that it thinks DST starts
on April 26, and ends on October 25, which is not correct.
[...]

You don't mention which version of Ubuntu, but apt-get may have updated
your tzdata, already. You'll need to update your Sun tables, too.

<http://java.sun.com/javase/tzupdater_README.html>
 
D

David Karr

 "david.karr said:
Here in Seattle, on April 14, we're in daylight savings time.  I've
noticed since DST started that log files created by Java applications
on my Ubuntu box are an hour behind.  I figured it had something to do
with daylight savings time.  Non-Java applications do not display this
symptom.
If it matters, here's the output of "java -version":
java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing)
I wrote a small test application that prints out relevant information
about daylight savings time.  I'll attach the test code, but the
output it produces follows this. You'll see that as of today, it
thinks DST is not in effect.  It also shows that it thinks DST starts
on April 26, and ends on October 25, which is not correct.

[...]

You don't mention which version of Ubuntu, but apt-get may have updated
your tzdata, already. You'll need to update your Sun tables, too.

<http://java.sun.com/javase/tzupdater_README.html>

I'm using Ubuntu 8.10.

Your information was promising, but it didn't appear to fix the
problem.

I installed the tzupdater tool, and then from the command line, I
first reran my test app to make sure it's reporting the same results
as it did before. Then, I ran the tzupdater with "-t". This showed
lots of output indicating various test failures and "time zone not
found" lines. Then, I ran it with "-u" and it chugged for a second
and went back to the prompt. I then reran my test app, and the
results didn't change. I then reran the tzupdater with "-t", and it
produced no output. This tells me that the update did something, but
not quite what I need.

I assume the timezone data is only relevant at runtime, so I shouldn't
have to recompile the class in my test app?
 
K

Knute Johnson

david.karr said:
Here in Seattle, on April 14, we're in daylight savings time. I've
noticed since DST started that log files created by Java applications
on my Ubuntu box are an hour behind. I figured it had something to do
with daylight savings time. Non-Java applications do not display this
symptom.

If it matters, here's the output of "java -version":

java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing)

I wrote a small test application that prints out relevant information
about daylight savings time. I'll attach the test code, but the
output it produces follows this. You'll see that as of today, it
thinks DST is not in effect. It also shows that it thinks DST starts
on April 26, and ends on October 25, which is not correct.

I filed a Ubuntu bug report for this, but I'd like to get some
feedback from "this side of the house" to see why this might be
happening.

date[Mon Apr 13 13:04:01 PST 2009] zonename[Pacific Standard Time]
dstSavings[3600000] usesDST[true] inDST[false] rawOffset[-28800000]
offset[-28800000]
date[Mon Apr 13 13:04:01 PST 2009] inDST[false]
date[Wed May 13 13:04:01 PDT 2009] inDST[true]
date[Sat Jun 13 13:04:01 PDT 2009] inDST[true]
date[Mon Jul 13 13:04:01 PDT 2009] inDST[true]
date[Thu Aug 13 13:04:01 PDT 2009] inDST[true]
date[Sun Sep 13 13:04:01 PDT 2009] inDST[true]
date[Tue Oct 13 13:04:01 PDT 2009] inDST[true]
date[Fri Nov 13 13:04:01 PST 2009] inDST[false]
date[Sun Dec 13 13:04:01 PST 2009] inDST[false]
date[Wed Jan 13 13:04:01 PST 2010] inDST[false]
date[Sat Feb 13 13:04:01 PST 2010] inDST[false]
date[Sat Mar 13 13:04:01 PST 2010] inDST[false]
date[Sun Apr 26 00:00:00 PST 2009] inDST[false]
date[Mon Apr 27 00:00:00 PDT 2009] inDST[true]
date[Sun Oct 25 00:00:00 PDT 2009] inDST[true]
date[Mon Oct 26 00:00:00 PST 2009] inDST[false]

Linux has all sorts of issues with timezones and so does Java. So if
your system is not completely updated, both the Linux and Java, there
could be timezone problems. And that means the _?? updates of Java too.
That said, you can do an immediate fix by putting adding a link,

/etc/localtime that points to /usr/share/zoneinfo/US/Pacific

This will get changed to the correct file and not a link when you do all
the updates but it works fine until then.

To confirm correct Java time, run my clock applet

http://rabbitbrush.frazmtn.com/clock.html

and check your time.

knute...
 
J

John B. Matthews

David Karr said:
 "david.karr said:
Here in Seattle, on April 14, we're in daylight savings time.
 I've noticed since DST started that log files created by Java
applications on my Ubuntu box are an hour behind.  I figured it
had something to do with daylight savings time.  Non-Java
applications do not display this symptom.
If it matters, here's the output of "java -version":
java version "1.6.0_10" Java(TM) SE Runtime Environment (build
1.6.0_10-b33) Java HotSpot(TM) Client VM (build 11.0-b15, mixed
mode, sharing)
I wrote a small test application that prints out relevant
information about daylight savings time.  I'll attach the test
code, but the output it produces follows this. You'll see that as
of today, it thinks DST is not in effect.  It also shows that it
thinks DST starts on April 26, and ends on October 25, which is
not correct.

[...]

You don't mention which version of Ubuntu, but apt-get may have
updated your tzdata, already. You'll need to update your Sun
tables, too.

<http://java.sun.com/javase/tzupdater_README.html>

I'm using Ubuntu 8.10.

Good, you can get updates. Be sure your tzdata is current. It looks like
tzdata 2009d-0ubuntu0.8.10 was accepted 30-Mar-2009.
Your information was promising, but it didn't appear to fix the
problem.

I installed the tzupdater tool, and then from the command line, I
first reran my test app to make sure it's reporting the same results
as it did before. Then, I ran the tzupdater with "-t". This showed
lots of output indicating various test failures and "time zone not
found" lines. Then, I ran it with "-u" and it chugged for a second
and went back to the prompt. I then reran my test app, and the
results didn't change. I then reran the tzupdater with "-t", and it
produced no output. This tells me that the update did something, but
not quite what I need.

I assume the timezone data is only relevant at runtime, so I
shouldn't have to recompile the class in my test app?

I wouldn't think so, but your attached code wasn't propagated.
 
D

David Karr

david.karr said:
Here in Seattle, on April 14, we're in daylight savings time.  I've
noticed since DST started that log files created by Java applications
on my Ubuntu box are an hour behind.  I figured it had something to do
with daylight savings time.  Non-Java applications do not display this
symptom.
If it matters, here's the output of "java -version":
java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing)
I wrote a small test application that prints out relevant information
about daylight savings time.  I'll attach the test code, but the
output it produces follows this. You'll see that as of today, it
thinks DST is not in effect.  It also shows that it thinks DST starts
on April 26, and ends on October 25, which is not correct.
I filed a Ubuntu bug report for this, but I'd like to get some
feedback from "this side of the house" to see why this might be
happening.
date[Mon Apr 13 13:04:01 PST 2009] zonename[Pacific Standard Time]
dstSavings[3600000] usesDST[true] inDST[false] rawOffset[-28800000]
offset[-28800000]
date[Mon Apr 13 13:04:01 PST 2009] inDST[false]
date[Wed May 13 13:04:01 PDT 2009] inDST[true]
date[Sat Jun 13 13:04:01 PDT 2009] inDST[true]
date[Mon Jul 13 13:04:01 PDT 2009] inDST[true]
date[Thu Aug 13 13:04:01 PDT 2009] inDST[true]
date[Sun Sep 13 13:04:01 PDT 2009] inDST[true]
date[Tue Oct 13 13:04:01 PDT 2009] inDST[true]
date[Fri Nov 13 13:04:01 PST 2009] inDST[false]
date[Sun Dec 13 13:04:01 PST 2009] inDST[false]
date[Wed Jan 13 13:04:01 PST 2010] inDST[false]
date[Sat Feb 13 13:04:01 PST 2010] inDST[false]
date[Sat Mar 13 13:04:01 PST 2010] inDST[false]
date[Sun Apr 26 00:00:00 PST 2009] inDST[false]
date[Mon Apr 27 00:00:00 PDT 2009] inDST[true]
date[Sun Oct 25 00:00:00 PDT 2009] inDST[true]
date[Mon Oct 26 00:00:00 PST 2009] inDST[false]

Linux has all sorts of issues with timezones and so does Java.  So if
your system is not completely updated, both the Linux and Java, there
could be timezone problems.  And that means the _?? updates of Java too..
  That said, you can do an immediate fix by putting adding a link,

/etc/localtime that points to /usr/share/zoneinfo/US/Pacific

I didn't make this change, but I did run "cmp" with those two file
paths as arguments, so I assume that means they are identical, which
makes the change unnecessary.
This will get changed to the correct file and not a link when you do all
the updates but it works fine until then.

To confirm correct Java time, run my clock applet

http://rabbitbrush.frazmtn.com/clock.html

and check your time.

Still an hour behind.
 
D

David Karr

<3acf3c31-e7c6-40ff-8127-a40b8debe...@y10g2000prc.googlegroups.com>,
Here in Seattle, on April 14, we're in daylight savings time.
 I've noticed since DST started that log files created by Java
applications on my Ubuntu box are an hour behind.  I figured it
had something to do with daylight savings time.  Non-Java
applications do not display this symptom.
If it matters, here's the output of "java -version":
java version "1.6.0_10" Java(TM) SE Runtime Environment (build
1.6.0_10-b33) Java HotSpot(TM) Client VM (build 11.0-b15, mixed
mode, sharing)
I wrote a small test application that prints out relevant
information about daylight savings time.  I'll attach the test
code, but the output it produces follows this. You'll see that as
of today, it thinks DST is not in effect.  It also shows that it
thinks DST starts on April 26, and ends on October 25, which is
not correct.
[...]
You don't mention which version of Ubuntu, but apt-get may have
updated your tzdata, already. You'll need to update your Sun
tables, too.
<http://java.sun.com/javase/tzupdater_README.html>
I'm using Ubuntu 8.10.

Good, you can get updates. Be sure your tzdata is current. It looks like
tzdata 2009d-0ubuntu0.8.10 was accepted 30-Mar-2009.
Your information was promising, but it didn't appear to fix the
problem.
I installed the tzupdater tool, and then from the command line, I
first reran my test app to make sure it's reporting the same results
as it did before.  Then, I ran the tzupdater with "-t".  This showed
lots of output indicating various test failures and "time zone not
found" lines.  Then, I ran it with "-u" and it chugged for a second
and went back to the prompt.  I then reran my test app, and the
results didn't change.  I then reran the tzupdater with "-t", and it
produced no output.  This tells me that the update did something, but
not quite what I need.
I assume the timezone data is only relevant at runtime, so I
shouldn't have to recompile the class in my test app?

I wouldn't think so, but your attached code wasn't propagated.

That's because I didn't attach it.

I'll add two blocks here, one with the code for the class, and one
showing the current output I get.
------------------------------
package timedate;

import java.text.DateFormat;
import java.util.Calendar;
import java.util.Date;
import java.util.TimeZone;

import
com.sun.org.apache.xerces.internal.impl.xpath.regex.ParseException;

public class TimeDate
{
public static void main(String[] args)
{
TimeZone timezone = TimeZone.getDefault();
Date date = new Date();
System.out.println("date[" + date +
"] zonename[" + timezone.getDisplayName() +
"] dstSavings[" + timezone.getDSTSavings()
+
"] usesDST[" + timezone.useDaylightTime() +
"] inDST[" + timezone.inDaylightTime(date)
+
"] rawOffset[" + timezone.getRawOffset() +
"] offset[" + timezone.getOffset
(date.getTime()) + "]");
Calendar calendar = Calendar.getInstance();
for (int ctr = 0; ctr < 12; ++ ctr)
{
testDateForDST(calendar.getTime());
calendar.add(Calendar.MONTH, 1);
}

testDateStrForDST("April 26, 2009");
testDateStrForDST("April 27, 2009");
testDateStrForDST("October 25, 2009");
testDateStrForDST("October 26, 2009");
}

public static void testDateForDST(Date date)
{
System.out.println("date[" + date +
"] inDST[" + inDST(Calendar.getInstance().getTimeZone
(), date) + "]");

}

public static void testDateStrForDST(String str)
{
DateFormat dateFormat = DateFormat.getDateInstance();

try
{
Date date = dateFormat.parse(str);
testDateForDST(date);
}
catch (Exception ex)
{
ex.printStackTrace();
}
}

public static boolean inDST(TimeZone timeZone, Date date)
{
return Calendar.getInstance().getTimeZone().inDaylightTime
(date);
}
}
------------------------------
------------------------------
date[Mon Apr 13 13:04:01 PST 2009] zonename[Pacific Standard Time]
dstSavings[3600000] usesDST[true] inDST[false] rawOffset[-28800000]
offset[-28800000]
date[Mon Apr 13 13:04:01 PST 2009] inDST[false]
date[Wed May 13 13:04:01 PDT 2009] inDST[true]
date[Sat Jun 13 13:04:01 PDT 2009] inDST[true]
date[Mon Jul 13 13:04:01 PDT 2009] inDST[true]
date[Thu Aug 13 13:04:01 PDT 2009] inDST[true]
date[Sun Sep 13 13:04:01 PDT 2009] inDST[true]
date[Tue Oct 13 13:04:01 PDT 2009] inDST[true]
date[Fri Nov 13 13:04:01 PST 2009] inDST[false]
date[Sun Dec 13 13:04:01 PST 2009] inDST[false]
date[Wed Jan 13 13:04:01 PST 2010] inDST[false]
date[Sat Feb 13 13:04:01 PST 2010] inDST[false]
date[Sat Mar 13 13:04:01 PST 2010] inDST[false]
date[Sun Apr 26 00:00:00 PST 2009] inDST[false]
date[Mon Apr 27 00:00:00 PDT 2009] inDST[true]
date[Sun Oct 25 00:00:00 PDT 2009] inDST[true]
date[Mon Oct 26 00:00:00 PST 2009] inDST[false]
---------------------------------
 
K

Knute Johnson

David said:
david.karr said:
Here in Seattle, on April 14, we're in daylight savings time. I've
noticed since DST started that log files created by Java applications
on my Ubuntu box are an hour behind. I figured it had something to do
with daylight savings time. Non-Java applications do not display this
symptom.
If it matters, here's the output of "java -version":
java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing)
I wrote a small test application that prints out relevant information
about daylight savings time. I'll attach the test code, but the
output it produces follows this. You'll see that as of today, it
thinks DST is not in effect. It also shows that it thinks DST starts
on April 26, and ends on October 25, which is not correct.
I filed a Ubuntu bug report for this, but I'd like to get some
feedback from "this side of the house" to see why this might be
happening.
date[Mon Apr 13 13:04:01 PST 2009] zonename[Pacific Standard Time]
dstSavings[3600000] usesDST[true] inDST[false] rawOffset[-28800000]
offset[-28800000]
date[Mon Apr 13 13:04:01 PST 2009] inDST[false]
date[Wed May 13 13:04:01 PDT 2009] inDST[true]
date[Sat Jun 13 13:04:01 PDT 2009] inDST[true]
date[Mon Jul 13 13:04:01 PDT 2009] inDST[true]
date[Thu Aug 13 13:04:01 PDT 2009] inDST[true]
date[Sun Sep 13 13:04:01 PDT 2009] inDST[true]
date[Tue Oct 13 13:04:01 PDT 2009] inDST[true]
date[Fri Nov 13 13:04:01 PST 2009] inDST[false]
date[Sun Dec 13 13:04:01 PST 2009] inDST[false]
date[Wed Jan 13 13:04:01 PST 2010] inDST[false]
date[Sat Feb 13 13:04:01 PST 2010] inDST[false]
date[Sat Mar 13 13:04:01 PST 2010] inDST[false]
date[Sun Apr 26 00:00:00 PST 2009] inDST[false]
date[Mon Apr 27 00:00:00 PDT 2009] inDST[true]
date[Sun Oct 25 00:00:00 PDT 2009] inDST[true]
date[Mon Oct 26 00:00:00 PST 2009] inDST[false]
Linux has all sorts of issues with timezones and so does Java. So if
your system is not completely updated, both the Linux and Java, there
could be timezone problems. And that means the _?? updates of Java too.
That said, you can do an immediate fix by putting adding a link,

/etc/localtime that points to /usr/share/zoneinfo/US/Pacific

I didn't make this change, but I did run "cmp" with those two file
paths as arguments, so I assume that means they are identical, which
makes the change unnecessary.
This will get changed to the correct file and not a link when you do all
the updates but it works fine until then.

To confirm correct Java time, run my clock applet

http://rabbitbrush.frazmtn.com/clock.html

and check your time.

Still an hour behind.

Take out the file and put in the link. I think you will be surprised!

knute...
 
J

John B. Matthews

David Karr said:
Good, you can get updates. Be sure your tzdata is current. It looks
like tzdata 2009d-0ubuntu0.8.10 was accepted 30-Mar-2009.
[...]
I'll add two blocks here, one with the code for the class, and one
showing the current output I get. [...]
date[Sun Apr 26 00:00:00 PST 2009] inDST[false]
date[Mon Apr 27 00:00:00 PDT 2009] inDST[true]
date[Sun Oct 25 00:00:00 PDT 2009] inDST[true]
date[Mon Oct 26 00:00:00 PST 2009] inDST[false]

I get expected results from your code in my time zone. Your results are
incorrect for <http://en.wikipedia.org/wiki/Pacific_Time_Zone>. I see
the Pacific Time Zone changed in both 2006 and 2007, but 8.10 was
released in 2008. It's hard to imagine your tzdata being outdated, but
it's easy to check. You mention that Knute Johnson's Java Applet clock
displays an hour behind. Is your desktop clock also an hour behind? Are
you running under a VM or with altered BIOS settings?
 
D

David Karr

<http://java.sun.com/javase/tzupdater_README.html>
I'm using Ubuntu 8.10.
Good, you can get updates. Be sure your tzdata is current. It looks
like tzdata 2009d-0ubuntu0.8.10 was accepted 30-Mar-2009.
[...]
I'll add two blocks here, one with the code for the class, and one
showing the current output I get. [...]
date[Sun Apr 26 00:00:00 PST 2009] inDST[false]
date[Mon Apr 27 00:00:00 PDT 2009] inDST[true]
date[Sun Oct 25 00:00:00 PDT 2009] inDST[true]
date[Mon Oct 26 00:00:00 PST 2009] inDST[false]

I get expected results from your code in my time zone. Your results are
incorrect for <http://en.wikipedia.org/wiki/Pacific_Time_Zone>. I see
the Pacific Time Zone changed in both 2006 and 2007, but 8.10 was
released in 2008. It's hard to imagine your tzdata being outdated, but
it's easy to check. You mention that Knute Johnson's Java Applet clock
displays an hour behind. Is your desktop clock also an hour behind? Are
you running under a VM or with altered BIOS settings?

No, as I said in the original post, all non-Java applications do not
display this symptom. I'm not running in a VM. If it matters, I just
ran tzupdater, as you can see earlier in this thread.
 
D

David Karr

david.karr said:
Here in Seattle, on April 14, we're in daylight savings time.  I've
noticed since DST started that log files created by Java applications
on my Ubuntu box are an hour behind.  I figured it had something to do
with daylight savings time.  Non-Java applications do not display this
symptom.
If it matters, here's the output of "java -version":
java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing)
I wrote a small test application that prints out relevant information
about daylight savings time.  I'll attach the test code, but the
output it produces follows this. You'll see that as of today, it
thinks DST is not in effect.  It also shows that it thinks DST starts
on April 26, and ends on October 25, which is not correct.
I filed a Ubuntu bug report for this, but I'd like to get some
feedback from "this side of the house" to see why this might be
happening.
date[Mon Apr 13 13:04:01 PST 2009] zonename[Pacific Standard Time]
dstSavings[3600000] usesDST[true] inDST[false] rawOffset[-28800000]
offset[-28800000]
date[Mon Apr 13 13:04:01 PST 2009] inDST[false]
date[Wed May 13 13:04:01 PDT 2009] inDST[true]
date[Sat Jun 13 13:04:01 PDT 2009] inDST[true]
date[Mon Jul 13 13:04:01 PDT 2009] inDST[true]
date[Thu Aug 13 13:04:01 PDT 2009] inDST[true]
date[Sun Sep 13 13:04:01 PDT 2009] inDST[true]
date[Tue Oct 13 13:04:01 PDT 2009] inDST[true]
date[Fri Nov 13 13:04:01 PST 2009] inDST[false]
date[Sun Dec 13 13:04:01 PST 2009] inDST[false]
date[Wed Jan 13 13:04:01 PST 2010] inDST[false]
date[Sat Feb 13 13:04:01 PST 2010] inDST[false]
date[Sat Mar 13 13:04:01 PST 2010] inDST[false]
date[Sun Apr 26 00:00:00 PST 2009] inDST[false]
date[Mon Apr 27 00:00:00 PDT 2009] inDST[true]
date[Sun Oct 25 00:00:00 PDT 2009] inDST[true]
date[Mon Oct 26 00:00:00 PST 2009] inDST[false]

Linux has all sorts of issues with timezones and so does Java.  So if
your system is not completely updated, both the Linux and Java, there
could be timezone problems.  And that means the _?? updates of Java too..
  That said, you can do an immediate fix by putting adding a link,

/etc/localtime that points to /usr/share/zoneinfo/US/Pacific

Ok, that worked. Can you please explain how that works (especially
the part about the two original files being identical)? I'd like to
add some info to the Ubuntu bug report.
This will get changed to the correct file and not a link when you do all
the updates but it works fine until then.

What updates are you talking about? I have no pending package
updates, and I've already run tzupdater.
To confirm correct Java time, run my clock applet

http://rabbitbrush.frazmtn.com/clock.html

and check your time.

This appears to be down right now.
 
J

John B. Matthews

David Karr said:
I'm using Ubuntu 8.10.
Good, you can get updates. Be sure your tzdata is current. It looks
like tzdata 2009d-0ubuntu0.8.10 was accepted 30-Mar-2009. [...]
I'll add two blocks here, one with the code for the class, and one
showing the current output I get. [...]
date[Sun Apr 26 00:00:00 PST 2009] inDST[false]
date[Mon Apr 27 00:00:00 PDT 2009] inDST[true]
date[Sun Oct 25 00:00:00 PDT 2009] inDST[true]
date[Mon Oct 26 00:00:00 PST 2009] inDST[false]

I get expected results from your code in my time zone. Your results
are incorrect for <http://en.wikipedia.org/wiki/Pacific_Time_Zone>.
I see the Pacific Time Zone changed in both 2006 and 2007, but 8.10
was released in 2008. It's hard to imagine your tzdata being
outdated, but it's easy to check. You mention that Knute Johnson's
Java Applet clock displays an hour behind. Is your desktop clock
also an hour behind? Are you running under a VM or with altered
BIOS settings?

No, as I said in the original post, all non-Java applications do not
display this symptom. I'm not running in a VM. If it matters, I
just ran tzupdater, as you can see earlier in this thread.

Ah, only Java applications display the symptom. I'm sure you've also
verified that you have only one JDK/JRE installed.

I am intrigued that linking /etc/localtime to the correct zoneinfo
helped: /usr/share/zoneinfo/US/Pacific. I seem to recall the tzdata
update generating changed files as part of the update process.
 
D

David Karr

[...]
<http://java.sun.com/javase/tzupdater_README.html>
I'm using Ubuntu 8.10.
Good, you can get updates. Be sure your tzdata is current. It looks
like tzdata 2009d-0ubuntu0.8.10 was accepted 30-Mar-2009.
[...]
I'll add two blocks here, one with the code for the class, and one
showing the current output I get.
[...]
date[Sun Apr 26 00:00:00 PST 2009] inDST[false]
date[Mon Apr 27 00:00:00 PDT 2009] inDST[true]
date[Sun Oct 25 00:00:00 PDT 2009] inDST[true]
date[Mon Oct 26 00:00:00 PST 2009] inDST[false]
I get expected results from your code in my time zone. Your results
are incorrect for <http://en.wikipedia.org/wiki/Pacific_Time_Zone>.
I see the Pacific Time Zone changed in both 2006 and 2007, but 8.10
was released in 2008. It's hard to imagine your tzdata being
outdated, but it's easy to check. You mention that Knute Johnson's
Java Applet clock displays an hour behind. Is your desktop clock
also an hour behind? Are you running under a VM or with altered
BIOS settings?
No, as I said in the original post, all non-Java applications do not
display this symptom.  I'm not running in a VM.  If it matters, I
just ran tzupdater, as you can see earlier in this thread.

Ah, only Java applications display the symptom. I'm sure you've also
verified that you have only one JDK/JRE installed.

Are you kidding? There are several. I've only been testing with the
"main" one to see if anything I did would impact at least that JVM. I
would assume that the localtime link change would have affected all of
them.
 
J

John B. Matthews

David Karr said:
Good, you can get updates. Be sure your tzdata is current. It looks
like tzdata 2009d-0ubuntu0.8.10 was accepted 30-Mar-2009.
[...]
I'll add two blocks here, one with the code for the class, and one
showing the current output I get.
[...]
date[Sun Apr 26 00:00:00 PST 2009] inDST[false]
date[Mon Apr 27 00:00:00 PDT 2009] inDST[true]
date[Sun Oct 25 00:00:00 PDT 2009] inDST[true]
date[Mon Oct 26 00:00:00 PST 2009] inDST[false]
I get expected results from your code in my time zone. Your results
are incorrect for <http://en.wikipedia.org/wiki/Pacific_Time_Zone>.
I see the Pacific Time Zone changed in both 2006 and 2007, but 8.10
was released in 2008. It's hard to imagine your tzdata being
outdated, but it's easy to check. You mention that Knute Johnson's
Java Applet clock displays an hour behind. Is your desktop clock
also an hour behind? Are you running under a VM or with altered
BIOS settings?
No, as I said in the original post, all non-Java applications do not
display this symptom.  I'm not running in a VM.  If it matters, I
just ran tzupdater, as you can see earlier in this thread.

Ah, only Java applications display the symptom. I'm sure you've also
verified that you have only one JDK/JRE installed.

Are you kidding?

No, but I understand that the distinction can be difficult in text and
among people with different language & cultural backgrounds.

Were I kidding, I'd actually be calving, albeit at a glacial pace. :)
There are several. I've only been testing with the "main" one to see
if anything I did would impact at least that JVM. I would assume
that the localtime link change would have affected all of them.

 
D

David Karr

[...]
<http://java.sun.com/javase/tzupdater_README.html>
I'm using Ubuntu 8.10.
Good, you can get updates. Be sure your tzdata is current. It looks
like tzdata 2009d-0ubuntu0.8.10 was accepted 30-Mar-2009.
[...]
I'll add two blocks here, one with the code for the class, and one
showing the current output I get.
[...]
date[Sun Apr 26 00:00:00 PST 2009] inDST[false]
date[Mon Apr 27 00:00:00 PDT 2009] inDST[true]
date[Sun Oct 25 00:00:00 PDT 2009] inDST[true]
date[Mon Oct 26 00:00:00 PST 2009] inDST[false]
I get expected results from your code in my time zone. Your results
are incorrect for <http://en.wikipedia.org/wiki/Pacific_Time_Zone>.
I see the Pacific Time Zone changed in both 2006 and 2007, but 8.10
was released in 2008. It's hard to imagine your tzdata being
outdated, but it's easy to check. You mention that Knute Johnson's
Java Applet clock displays an hour behind. Is your desktop clock
also an hour behind? Are you running under a VM or with altered
BIOS settings?
No, as I said in the original post, all non-Java applications do not
display this symptom.  I'm not running in a VM.  If it matters, I
just ran tzupdater, as you can see earlier in this thread.
Ah, only Java applications display the symptom. I'm sure you've also
verified that you have only one JDK/JRE installed.
There are several.  I've only been testing with the "main" one to see
if anything I did would impact at least that JVM.  I would assume
that the localtime link change would have affected all of them.

See also <http://java.sun.com/javase/tzupdater_README.html#system>

Yes, that page was already referenced earlier in this thread. I
didn't see any point in running tzupdater on the other JVMs, as it had
no effect on the JVM that I've been testing with.
 
J

John B. Matthews

David Karr said:
Yes, that page was already referenced earlier in this thread. I
didn't see any point in running tzupdater on the other JVMs, as it had
no effect on the JVM that I've been testing with.

I'm not sure you can say there was "no effect." IIRC, you updated the
JVM first and then fixed the link in /etc/localtime. In particular, you
got different results running "tzupdater -u" between successive
executions of "tzupdater -t" [*]. You will surely need to update all
installed JDK/JREs. I have a clear memory of anomalous results when I
overlooked this in the past.

[*] <http://groups.google.com/group/comp.lang.java.programmer/msg/79d7a8dd5076fd21>
 
D

David Karr

Yes, that page was already referenced earlier in this thread.  I
didn't see any point in running tzupdater on the other JVMs, as it had
no effect on the JVM that I've been testing with.

I'm not sure you can say there was "no effect." IIRC, you updated the
JVM first and then fixed the link in /etc/localtime. In particular, you
got different results running "tzupdater -u" between successive
executions of "tzupdater -t" [*]. You will surely need to update all
installed JDK/JREs. I have a clear memory of anomalous results when I
overlooked this in the past.

I ran my test showing the incorrect DST date range. I then ran
tzupdater with that JVM. I then ran my test again. The output was
identical to the first run, and still wrong. That's what I mean by
"no effect".

I then later made the "/etc/localtime" change and then ran my test,
and it was now correct, showing the correct DST date range.

I now just ran my test app using a completely different JVM that is
installed elsewhere on the system, without running tzupdater on it,
and it shows the correct DST date range.

And concerning the runs of "tzupdater", yes, I clearly got different
results from "tzupdater -t" after I ran "tzupdater -u". It still had
no apparent effect on my problem.
 
D

David Karr

Yes, that page was already referenced earlier in this thread.  I
didn't see any point in running tzupdater on the other JVMs, as it had
no effect on the JVM that I've been testing with.

I'm not sure you can say there was "no effect." IIRC, you updated the
JVM first and then fixed the link in /etc/localtime. In particular, you
got different results running "tzupdater -u" between successive
executions of "tzupdater -t" [*]. You will surely need to update all
installed JDK/JREs. I have a clear memory of anomalous results when I

I also just restarted the browser and tested the aforementioned clock
applet, and that also shows the correct time, using DST (I tried it
first before restarting the browser, and it was still wrong). I'm not
certain what JVM this uses (the Java console appears to be an add-on
that I don't have).
 
D

David Karr

I'm not sure you can say there was "no effect." IIRC, you updated the
JVM first and then fixed the link in /etc/localtime. In particular, you
got different results running "tzupdater -u" between successive
executions of "tzupdater -t" [*]. You will surely need to update all
installed JDK/JREs. I have a clear memory of anomalous results when I

I also just restarted the browser and tested the aforementioned clock
applet, and that also shows the correct time, using DST (I tried it
first before restarting the browser, and it was still wrong).  I'm not
certain what JVM this uses (the Java console appears to be an add-on
that I don't have).

Never mind on the console point. I figured that out. It shows it's
using the JVM I was using before.
 
K

Knute Johnson

David said:
Ok, that worked. Can you please explain how that works (especially
the part about the two original files being identical)? I'd like to
add some info to the Ubuntu bug report.

Sun's Java under Linux requires that /etc/localtime be a link. I have
no idea why. I can't tell you how long it took me to figure this out.
What updates are you talking about? I have no pending package
updates, and I've already run tzupdater.

You are good then. The timezone updates come with the JDK and since
Ubuntu doesn't do any updates mid-cycle you can end up with out of date
timezone data in Java. This is solved with the tzupdater. Keep in mind
though that Ubuntu updates can (and will) overwrite your /etc/localtime.
This appears to be down right now.

Sorry, ISP had some serious problems from early this morning until just
a little bit ago. Should work fine now.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top