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

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.
 
M

Mayeul

Knute said:
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.

Last time I checked, that was related to Java's need to detect what
timezone, and not what timezone rules, the system is configured to use.

The content of the files in /usr/share/zoneinfo, indicate a few rules
about the timezone, but it does not identify the timezone (and it lacks
DST information.) So Sun Java decided to identify it by the file's name.
Since, by definition, the file name is /etc/localtime, the idea was to
check what file it is a link to.

Now for the tricky part: in case /etc/localtime is not a link, the
fallback was to check all entries in /usr/share/zoneinfo, to find an
identical file, and decide this file's name indicates the timezone. A
problem I often encountered, was that several files were identical to
/etc/localtime, and Java would pick the wrong one.

But, I use the past because that would lead to incorrect timezone
detection, and here it seems that PST was detected just fine, the
problem being with DST rules. No idea what leaded to this precise problem.

If anyone has more up-to-date knowledge with the issue, I'd be delighted
to hear about it.
 
K

Knute Johnson

Mayeul said:
Last time I checked, that was related to Java's need to detect what
timezone, and not what timezone rules, the system is configured to use.

The content of the files in /usr/share/zoneinfo, indicate a few rules
about the timezone, but it does not identify the timezone (and it lacks
DST information.) So Sun Java decided to identify it by the file's name.
Since, by definition, the file name is /etc/localtime, the idea was to
check what file it is a link to.

Now for the tricky part: in case /etc/localtime is not a link, the
fallback was to check all entries in /usr/share/zoneinfo, to find an
identical file, and decide this file's name indicates the timezone. A
problem I often encountered, was that several files were identical to
/etc/localtime, and Java would pick the wrong one.

But, I use the past because that would lead to incorrect timezone
detection, and here it seems that PST was detected just fine, the
problem being with DST rules. No idea what leaded to this precise problem.

If anyone has more up-to-date knowledge with the issue, I'd be delighted
to hear about it.

Thanks very much for the info Mayeul. I knew there had to be a reason,
just didn't know what it was.
 
D

David Karr

Last time I checked, that was related to Java's need to detect what
timezone, and not what timezone rules, the system is configured to use.

The content of the files in /usr/share/zoneinfo, indicate a few rules
about the timezone, but it does not identify the timezone (and it lacks
DST information.) So Sun Java decided to identify it by the file's name.
Since, by definition, the file name is /etc/localtime, the idea was to
check what file it is a link to.

Now for the tricky part: in case /etc/localtime is not a link, the
fallback was to check all entries in /usr/share/zoneinfo, to find an
identical file, and decide this file's name indicates the timezone. A
problem I often encountered, was that several files were identical to
/etc/localtime, and Java would pick the wrong one.

But, I use the past because that would lead to incorrect timezone
detection, and here it seems that PST was detected just fine, the
problem being with DST rules. No idea what leaded to this precise problem..

If anyone has more up-to-date knowledge with the issue, I'd be delighted
to hear about it.

Someone pointed me to the following Sun bug, which is very relevant:
<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6456628>.
 
R

Roedy Green

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?

Another tool that might be helpful in diagnosis is
http://mindprod.com/webstart/setclock.html

Other than screwed up timezone tables, the following can also muck up
the time:

1. the computer internal clock does not have accurate GMT -- corrected
by talking to an atomic clock.

2. the OS timezone for this computer is wrong, corrected in the
control panel.


--
Roedy Green Canadian Mind Products
http://mindprod.com

Now for something completely different:
 
R

Roedy Green

No, as I said in the original post, all non-Java applications do not
display this symptom. I

on the other paw, people running other Java apps on other platforms
don't see your problem. So the problem could be with:

1. your app

2. some sort of tables unique to the Ubuntu-Java combo you are using.
--
Roedy Green Canadian Mind Products
http://mindprod.com

Now for something completely different:
 
R

Roedy Green

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

Right. An old Java would not know about recent fiddle in start time.
--
Roedy Green Canadian Mind Products
http://mindprod.com

Now for something completely different:
 
L

Lew

David Karr
Roedy said:
on the other paw, people running other Java apps on other platforms
don't see your problem. So the problem could be with:

1. your app

2. some sort of tables unique to the Ubuntu-Java combo you are using.

I'm running Java 1.6.0-13 on Ubuntu 8.10 and the OP's test program (modified
to coerce the same date/time as his example) shows:

date[Mon Apr 13 16:04:01 EDT 2009] zonename[Pacific Standard Time]
dstSavings[3600000] usesDST[true] inDST[true] rawOffset[-28800000]
offset[-25200000]
date[Mon Apr 13 13:04:01 PDT 2009] inDST[true]
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 24:00:00 PDT 2009] inDST[true]
date[Mon Apr 27 24:00:00 PDT 2009] inDST[true]
date[Sun Oct 25 24:00:00 PDT 2009] inDST[true]
date[Mon Oct 26 24:00:00 PDT 2009] inDST[true]
 
D

David Karr

Unsurprisingly, I just got the update yesterday morning for tzdata and
tzdata-java 2009f, and after running it, my /etc/localtime was now a
hard file, and my test failed again. I restored it as a symlink, and
then the test succeeded again. The file list for either of those
packages does not include /etc/localtime, but "tzdata" does include
the file that I have /etc/localtime symlinked to. That's my best
guess of the package that could be doing this, but I'm not certain how
the installation process works.
 
K

Knute Johnson

David said:
Unsurprisingly, I just got the update yesterday morning for tzdata and
tzdata-java 2009f, and after running it, my /etc/localtime was now a
hard file, and my test failed again. I restored it as a symlink, and
then the test succeeded again. The file list for either of those
packages does not include /etc/localtime, but "tzdata" does include
the file that I have /etc/localtime symlinked to. That's my best
guess of the package that could be doing this, but I'm not certain how
the installation process works.

David:

I did not get the tzdata-java update and my link was overwritten so it
must be the tzdata package that's causing the problem. I'm not a Linux
expert by any stretch but do you think a hard link would survive the
overwrite or will it not work correctly once the linked file has been
overwritten?
 
M

Mayeul

Knute said:
David:

I did not get the tzdata-java update and my link was overwritten so it
must be the tzdata package that's causing the problem. I'm not a Linux
expert by any stretch but do you think a hard link would survive the
overwrite or will it not work correctly once the linked file has been
overwritten?

I'm not sure about the hard linking question, and would need to test for it.

But anyway, since the linux distribution decided to have /etc/localtime
as a copy of some file in /usr/share/zoneinfo, it would only be logical
that an update of tzdata would automatically update /etc/localtime too,
making it a copy of the same possibly-updated file in /usr/share/zoneinfo.

That's what Ubuntu looks like doing for me when I update
/usr/share/zoneinfo : remove the link and put a plain file that is a
copy of /usr/share/zoneinfo/Europe/Paris. Annoying but consistent with
the breaking behavior in the first place.

I suppose it does it with some post-update script.
 
J

John B. Matthews

[...]
But anyway, since the linux distribution decided to have
/etc/localtime as a copy of some file in /usr/share/zoneinfo, it
would only be logical that an update of tzdata would automatically
update /etc/localtime too, making it a copy of the same
possibly-updated file in /usr/share/zoneinfo.

That's what Ubuntu looks like doing for me when I update
/usr/share/zoneinfo : remove the link and put a plain file that is a
copy of /usr/share/zoneinfo/Europe/Paris. Annoying but consistent
with the breaking behavior in the first place.

I suppose it does it with some post-update script.

I went back through some logs on older Ubuntu distributions (6 & 7).
Using apt-get, an update to the package "locales" always left an
existing soft link in /etc/localtime alone.
 
D

David Karr

I'm not sure about the hard linking question, and would need to test for it.

But anyway, since the linux distribution decided to have /etc/localtime
as a copy of some file in /usr/share/zoneinfo, it would only be logical
that an update of tzdata would automatically update /etc/localtime too,
making it a copy of the same possibly-updated file in /usr/share/zoneinfo..

That's what Ubuntu looks like doing for me when I update
/usr/share/zoneinfo : remove the link and put a plain file that is a
copy of /usr/share/zoneinfo/Europe/Paris. Annoying but consistent with
the breaking behavior in the first place.

I suppose it does it with some post-update script.

Yes, it was pointed out to me that "/var/lib/dpkg/info/
tzdata.postinst" has the following block of code:

# Update the timezone
echo $AREA/$ZONE > /etc/timezone
rm -f /etc/localtime && \
cp -f /usr/share/zoneinfo/$AREA/$ZONE /etc/localtime
 

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,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top