** Changed in: sun-java5 (Debian)
Status: New => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/49068
Title:
Java reports time zone incorrectly during CDT (US Daylight saving
ti
Re: "Java 6u20 is available for Ubuntu 10.04 as of today!"
Just a note, I forgot that I had enabled the Canonical Partner repo on
this system. That is where this version of sun-java6-* is available
from. So to get it, you'll need to add this to your apt sources:
deb http://archive.canonical.com/
Looks like this was fixed in Java 6u18!
http://java.sun.com/javase/6/webnotes/6u18.html
==> 6456628 javaclasses_util_i18n (tz) Default timezone is
incorrectly set occasionally on Linux
(Sun Bug #6456628 is now listed as "Fix Shipped")
Java 6u20 is available for Ubuntu 10.04 as of
I'm on the latest version of Ubuntu 9.10 with Java 1.6.0_15-b03 and I
ran into the exact same problem. Had to create a symlink for
/etc/localtime.
According to sun this is fixed in 1.6.0_18-b02. Would it be possible to
get the repository updated with the newest version (I looked around and
couldn'
Please fix this bug. We are deploying ubuntu in our environment, and
have many java developpers.
All have to create a symlink to /usr/share/zoneinfo/Europe/Madrid
Thank you
--
Java reports time zone incorrectly during CDT (US Daylight saving time)
https://bugs.launchpad.net/bugs/49068
You recei
Allen Crider wrote:
> I would want any changes made to go into the Sun code where it
> would be maintained as part of the upstream version of the JVM.
Yes, you are right. I was only asking because I thought maybe it would be a
small patch, which Ubuntu manages quite a few, in which case it would
Arik Kfir wrote:
> I'm not familiar with the internals of the JVM, but why does a JVM even
> need its own database? Why can't it use the native OS's timezone
> database, just like it abstracts many other OS services.
>
> Although I'm a Java programmer, I firmly believe that managing the time
> zon
I'm not familiar with the internals of the JVM, but why does a JVM even
need its own database? Why can't it use the native OS's timezone
database, just like it abstracts many other OS services.
Although I'm a Java programmer, I firmly believe that managing the time
zone information is the system a
** Changed in: sun-java5 (Debian)
Status: Unknown => New
--
Java reports time zone incorrectly during CDT (US Daylight saving time)
https://bugs.launchpad.net/bugs/49068
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-b
** Bug watch added: Debian Bug tracker #416452
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=416452
** Also affects: sun-java5 (Debian) via
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=416452
Importance: Unknown
Status: Unknown
--
Java reports time zone incorrectly during
Matthias:
Are you referring to what a distributor can do for sun's JVM? The
solution I have put onto my ubuntu servers would require no changes to
Java. It would probably require changing tzconfig to write the timezone
out to a second place (/etc/sysconfig/clock)
--
Java reports time zone inco
Joe Kislo schrieb:
> I would strongly recommend a solution be found,
[...]
sure, you can recommend that, but read the license what a distributor is allowed
to do, and attach a patch which fixes the problem and is conforming to the
license.
--
Java reports time zone incorrectly during CDT (US Da
People were mentioning writing the correct timezone information to
/etc/sysconfig/clock aswell as an option, here is the format:
ZONE="America/New_York"
UTC=false
ARC=false
This doesn't seem like such a horrible idea. There may be even other
(non-ubuntu pieces of software) that use the /etc/sysc
A similar bug has already reported at Sun. It is marked as being in
progress, but I have no idea how long it might take until Sun takes care
of it.
See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6456628
Another fix for this bug might be to rewrite the scanning of
/usr/share/zoneinfo to co
> It sounds like we need to divide this into two bugs. My problem has a
> lot more to do with the localtime/TZ situation.
I agree. Because of the title of this bug, I suggest we keep track of the time
zone detection in this bug, and someone reports a new bug for the problem
regarding deprecated t
>It sounds like we need to divide this into two bugs. My problem has a
>lot more to do with the localtime/TZ situation.
As far as the localtime/TZ situation, why not just handle it during the
install of the jdk/jre? Determine if /etc/localtime is a link or not
and warn the user that they need to
Mike Green wrote:
>> You have to read Sun's statement you are quoting correctly. What it means:
>> You do not have to update data about the time zones, such as when DST begins
>> and ends, in your operating system. But Java detects the time zone you are in
>> the way I have described it. That's wha
>You have to read Sun's statement you are quoting correctly. What it means:
>You do not have to update data about the time zones, such as when DST begins
>and ends, in your operating system. But Java detects the time zone you are in
>the way I have described it. That's what I could see in the sourc
I should have thought about the possibility of having
/usr/share/zoneinfo on a different partition. And I had doubts about
changing tzconfig being a good solution as it did not appear to be easy
to wrap. It would be much easier (at least for me) to reproduce the
needed functionality in whatev
@Mike
You have to read Sun's statement you are quoting correctly. What it means: You
do not have to update data about the time zones, such as when DST begins and
ends, in your operating system. But Java detects the time zone you are in the
way I have described it. That's what I could see in the
Look guys, according to sun
(http://java.sun.com/developer/technicalArticles/Intl/USDST/):
"NOTE: The Java platform's time zone data is completely independent from
your operating system's time zone data. Therefore, you do not need to
update your operating system for the Java platform to work corre
Christian Assig wrote:
> I have had a look at the Java source code. It took me about 30 minutes to
> find the right file and analyse its behaviour.
> The time zone detection for Linux is implemented in
> j2se/src/solaris/native/java/util/TimeZone_md.c
>
> Java looks at the environment variable T
I have had a look at the Java source code. It took me about 30 minutes to find
the right file and analyse its behaviour.
The time zone detection for Linux is implemented in
j2se/src/solaris/native/java/util/TimeZone_md.c
Java looks at the environment variable TZ first.
If it is not set, it reads
Well, since it appears that the sun java package is not going to be
updated for dapper users, I might as well post my workaround. The sun
tzupdater package requires a registered account to download it, and I
have no idea what licensing restrictions it is distributed under. I
created this package
> That doesn't quite make sense. Java may have its own copy of the
> timezone database, but it must use something from the user or system to
> determine the timezone on the machine where it is running.
It makes sense if you consider that jvm's run on many platforms that
handle timezone information
Mike Green wrote:
> Please read
> http://java.sun.com/developer/technicalArticles/Intl/USDST_Faq.html,
> particularly question 9. The local timezone database, localtime links,
> and the TZ environment variable do not have anything to do with the
> problem (according to Sun).
>
That doesn't quite
Please read
http://java.sun.com/developer/technicalArticles/Intl/USDST_Faq.html,
particularly question 9. The local timezone database, localtime links,
and the TZ environment variable do not have anything to do with the
problem (according to Sun).
--
Java reports time zone incorrectly during CDT
I updated my edgy installation with sun-java5 to feisty with sun-java6
after feisty 's final release. This machine is still not affected by
this bug.
My other machine now shows the wrong time and time zone again, probably
because the symbolic link was overwritten during a package upgrade with
a re
Setting to confirmed because Allen can reproduce the behaviour
** Changed in: sun-java6 (Ubuntu)
Status: Unconfirmed => Confirmed
--
Java reports time zone incorrectly during CDT (US Daylight saving time)
https://bugs.launchpad.net/bugs/49068
You received this bug notification because you
Setting to confirmed because Allen can reproduce the behaviour
** Changed in: sun-java5 (Ubuntu)
Status: Unconfirmed => Confirmed
--
Java reports time zone incorrectly during CDT (US Daylight saving time)
https://bugs.launchpad.net/bugs/49068
You received this bug notification because you
This solution also works for me (creating a link to
/usr/share/zoneinfo/US/Central in my case). I originally reported this
bug against Dapper, but it seemed to go away with Edgy (DST was not in
effect when I installed Edgy and the problem did not appear when DST
started in March). However, it r
Something seemed to be wrong with /etc/localtime in my case.
The following solved the problem on my feisty machine:
sudo cp /etc/localtime /etc/localtime.bak
sudo ln -s -f /usr/share/zoneinfo/Europe/Amsterdam /etc/localtime
See http://ubuntuforums.org/showthread.php?p=2312649
Note however that
Another workaround is to set the environment variable TZ (for time zone
obviously), e.g. by executing
export TZ=`cat /etc/timezone`
If TZ is set, Sun's Java always uses its value under Linux.
See http://minaret.biz/tips/timezone.html
--
Java reports time zone incorrectly during CDT (US Daylight
I am also affected by this bug in continental Europe. I have two Kubuntu
installations, one is an edgy installation with sun-java5, the other one
is feisty with sun-java6.
I tried the sample application DateTest from
http://www.javaworld.com/javaworld/jw-10-2003/jw-1003-time.html
Edgy with Java 5
Note that I am not in the US, so should not be affected by the US
foobar. Java fails to report DST as 1 when my system clock is set to
summer, and I am in the UK (UTC and British Summer Time).
--
Java reports time zone incorrectly during CDT (US Daylight saving time)
https://launchpad.net/bugs/4
I've run the timezone updater as well, to fix my local JVM's zone
database but the package really should be synchronized with Sun's latest
1.5.X release (which does have proper DST values).
--
Java reports time zone incorrectly during CDT (US Daylight saving time)
https://launchpad.net/bugs/49068
The reason it reports an incorrect time zone is because sun java uses
its own time zone database. As far as I can tell anything below 1.6
needs to be patched for the upcoming DST changes. I have had to run the
timezone updater from Sun since no backports have been made available.
An awful lot of
Here is a link to a page with some validation code:
http://www.theserverside.com/tt/articles/article.tss?l=CountdownDST2007
--
Java reports time zone incorrectly during CDT (US Daylight saving time)
https://launchpad.net/bugs/49068
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https
You are explicitly setting the time in the constructor for
GregorianCalendar. Do you get the same results when you set your system
date and then use the default constructor for GregorianCalendar?
** Changed in: sun-java5 (Ubuntu)
Status: Needs Info => Unconfirmed
--
Java reports time zon
Happily. I'm in time zone CST, and I ran the following code:
import java.util.Calendar;
import java.util.Date;
import java.util.GregorianCalendar;
public class TimeTester
{
public static void main( String[] args )
{
Calendar calendar = new GregorianCalendar(106 + 1900, 6, 8);
//
Re-opening since I can still reproduce. Please show what you did
differently to make this not happen.
** Changed in: sun-java5 (Ubuntu)
Status: Rejected => Unconfirmed
--
Java reports time zone incorrectly during CDT (US Daylight saving time)
https://launchpad.net/bugs/49068
--
ubuntu-
I can still reproduce this. I'm really sorry, but I've done it on an
Edgy system, just to be difficult. I'd be really surprised if it's not
the same on both Dapper and Feisty.
[EMAIL PROTECTED]:~/cvs/java-test$ java -version
java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Editio
Seems to work for me here. Setting the date to June 1, 1997 as a test
case worked. 2006/06/08 (date this was filed) works as well. Considering
how long this has sat open with no attention, and my inability to
reproduce the problem, I'm going to close the bug report.
If you feel this is in error an
Obviously I cannot reproduce this at the current time (since it involves
daylight saving) but I have been searching the Java bugtracker to try
and see if I could find it reported there. Unfortunately there are quite
a few bug that may or may not be related. It is difficult for me to
determine since
44 matches
Mail list logo
