Diagnose why Pacific TZ has wrong start/stop dates for DST, with JDK 1.6 on Ubuntu
david.karr
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]
John B. Matthews
<3acf3c31-e7c6-40ff...@y10g2000prc.googlegroups.com>,
"david.karr" <davidmic...@gmail.com> wrote:
> 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>
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
David Karr
> In article
> <3acf3c31-e7c6-40ff-8127-a40b8debe...@y10g2000prc.googlegroups.com>,
>
>
>
> "david.karr" <davidmichaelk...@gmail.com> wrote:
> > 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?
Knute Johnson
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...
--
Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
------->>>>>>http://www.NewsDemon.com<<<<<<------
Unlimited Access, Anonymous Accounts, Uncensored Broadband Access
John B. Matthews
<57d025bf-2036-4835...@d25g2000prn.googlegroups.com>,
David Karr <davidmic...@gmail.com> wrote:
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.
David Karr
wrote:
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.
David Karr
> In article
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]
---------------------------------
Knute Johnson
Take out the file and put in the link. I think you will be surprised!
John B. Matthews
<04f84877-d1e6-4fdc...@b7g2000pre.googlegroups.com>,
David Karr <davidmic...@gmail.com> wrote:
[...]
> > > > <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?
David Karr
> In article
> David Karr <davidmichaelk...@gmail.com> wrote:
> [...]
>
> > > > > <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.
David Karr
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.
John B. Matthews
<bda90153-440f-483d...@z8g2000prd.googlegroups.com>,
David Karr <davidmic...@gmail.com> wrote:
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.
David Karr
> In article
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.
John B. Matthews
<eb5c3285-a3e8-4039...@f41g2000pra.googlegroups.com>,
David Karr <davidmic...@gmail.com> wrote:
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.
See also <http://java.sun.com/javase/tzupdater_README.html#system>
David Karr
> In article
> > 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.
John B. Matthews
<3c348e21-53a9-46f3...@y6g2000prf.googlegroups.com>,
David Karr <davidmic...@gmail.com> wrote:
> On Apr 15, 10:10 am, "John B. Matthews" <nos...@nospam.invalid> wrote:
[...]
> > > > 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.
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>
David Karr
> In article
> <3c348e21-53a9-46f3-892b-ba71c4b0d...@y6g2000prf.googlegroups.com>,
> David Karr <davidmichaelk...@gmail.com> wrote:
>
>
>
> > On Apr 15, 10:10 am, "John B. Matthews" <nos...@nospam.invalid> wrote:
> [...]
> > > > > 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.
>
> 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.
David Karr
> In article
> <3c348e21-53a9-46f3-892b-ba71c4b0d...@y6g2000prf.googlegroups.com>,
>
>
>
> > On Apr 15, 10:10 am, "John B. Matthews" <nos...@nospam.invalid> wrote:
> [...]
> > > > > 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.
>
> 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).
David Karr
Never mind on the console point. I figured that out. It shows it's
using the JVM I was using before.
David Karr
Never mind on the console point. I figured that out. It shows it's
Knute Johnson
>> 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.
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.
>> 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.
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.
>> 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.
Sorry, ISP had some serious problems from early this morning until just
a little bit ago. Should work fine now.
--
Knute Johnson
email s/nospam/knute2009/
Mayeul
> David Karr wrote:
>>> 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.
>
> 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.
--
Mayeul
Knute Johnson
Thanks very much for the info Mayeul. I knew there had to be a reason,
just didn't know what it was.
David Karr
Someone pointed me to the following Sun bug, which is very relevant:
<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6456628>.
Roedy Green
<nos...@nospam.invalid> wrote, quoted or indirectly quoted someone who
said :
>
>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:
http://www.youtube.com/watch?v=9lp0IWv8QZY
Roedy Green
<davidmic...@gmail.com> wrote, quoted or indirectly quoted
someone who said :
>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
<nos...@nospam.invalid> wrote, quoted or indirectly quoted someone who
said :
>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
<davidmic...@gmail.com> wrote, quoted or indirectly quoted
someone who said :
> public static void main(String[] args)
add this piece of code:
Roedy Green
<see_w...@mindprod.com.invalid> wrote, quoted or indirectly quoted
someone who said :
>> public static void main(String[] args)
>
>add this piece of code:
out.println( System.getProperty( "java.version" ) );
Lew
>> No, as I said in the original post, all non-Java applications do not
>> display this symptom. I
Roedy Green wrote:
> 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]
--
Lew
David Karr
wrote:
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.
Knute Johnson
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?
Mayeul
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.
--
Mayeul
John B. Matthews
Mayeul <mayeul....@free.fr> wrote:
[...]
> 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.
David Karr
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