loial wrote: > I am trying to convert BST times to EST.
What time zones do you mean here? Bangladesh Standard Time? British Summer Time? Eastern Standard Time in the Caribbean?
Neither "EST" nor "BST" is a standard time-zone name.
Have you considered reading the documentation?
> The following code correctly returns a difference of 5 hours between > the 2 times when run under Java 1.5. :
> Local Offset 3600000 > EST Offset -14400000 > EST time Tue May 04 07:48:18 2010
You do realize that Eastern Time is not "EST" on May 4 anywhere other than Australia, right? Any other jurisdiction that uses "EST" as an abbreviation is on Summer Time on that date. Therefore you must be referring to Australian time, but that's the wrong offset for that zone.
Please clarify.
In any case, there's nothing correct in what you show here. Why do you say this is a correct return?
> BST time Tue May 04 12:48:18 2010
Does Bangladesh have Daylight Saving Time?
> However if run under Java 1.6 (on the same machine), it returns a time > difference of 6 hours :
> Local Offset 3600000 > EST Offset -18000000 > EST time Tue May 04 06:48:18 2010 > BST time Tue May 04 12:48:18 2010
> Do I need to do something different in Java 1.6?.
Maybe give it the right time zone?
You do realize that Eastern Standard Time in the U.S. is -18000000 milliseconds offset from UTC, right? So if "EST" is "America/New_York" (and, of course, not Daylight Saving Time), then this display is correct.
What makes you think that it is not correct?
> Platform is linux [sic].
> class testtz {
Class names should start with an upper-case letter.
> public static void main(String[] args) {
> Date date = null;
Why do you set the date to 'null'? It's unnecessary and potentially harmful; it certainly is harmful in the code you show here.
> SimpleDateFormat dateFormat = new > SimpleDateFormat("yyyyMMddHHmmss");
> try {
> date = dateFormat.parse("20100504124818");
Here you throw away that 'null' value that you shouldn't have initialized.
"For compatibility with JDK 1.1.x, some other three-letter time zone IDs (such as "PST", "CTT", "AST") are also supported. However, their use is deprecated because the same abbreviation is often used for multiple time zones (for example, "CST" could be U.S. "Central Standard Time" and "China Standard Time"), and the Java platform can then only recognize one of them."
In message <fde67e7a-6198-4e7f-a07b-4655c1108...@j13g2000pro.googlegroups.com>, loial wrote:
> Platform is linux.
Linux has a perfectly serviceable set of timezone files available SYSTEMWIDE in /usr/share/zoneinfo; why do subsystems like Java insist on carrying around their own, potentially out-of-date and inconsistent copies?
On 24/05/2011 01:50, Lawrence D'Oliveiro allegedly wrote:
> In message > <fde67e7a-6198-4e7f-a07b-4655c1108...@j13g2000pro.googlegroups.com>, loial > wrote:
>> Platform is linux.
> Linux has a perfectly serviceable set of timezone files available SYSTEMWIDE > in /usr/share/zoneinfo; why do subsystems like Java insist on carrying > around their own, potentially out-of-date and inconsistent copies?
The JRE carries regularly updated timezone info (which can be updated independently of the JRE) for the purpose of running in environments that do not sport a perfectly serviceable set of timezone informations.
-- DF. An escaped convict once said to me: "Alcatraz is the place to be"
In message <iretd3$lg...@dont-email.me>, Daniele Futtorovic wrote:
> On 24/05/2011 01:50, Lawrence D'Oliveiro allegedly wrote:
>> Linux has a perfectly serviceable set of timezone files available >> SYSTEMWIDE in /usr/share/zoneinfo; why do subsystems like Java insist on >> carrying around their own, potentially out-of-date and inconsistent >> copies?
> The JRE carries regularly updated timezone info (which can be updated > independently of the JRE) for the purpose of running in environments > that do not sport a perfectly serviceable set of timezone informations.
Which is not the case with Linux. Why can it not use zoneinfo when it’s available?
Lawrence D'Oliveiro wrote: > In message <iretd3$lg...@dont-email.me>, Daniele Futtorovic wrote:
>> The JRE carries regularly updated timezone info (which can be updated >> independently of the JRE) for the purpose of running in environments >> that do not sport a perfectly serviceable set of timezone informations.
> Which is not the case with Linux. Why can it not use zoneinfo when it¢s > available?
Because these files are part of the runtime-classes which are Java and are therefor platform independent. BTW: How is Linux ensuring that the timezone-files are staying correct? I assume by doing the same thing that you do with Java: Update to the most current version. Since you do this update for other reasons as well (bugfixes, more performance, etc.) I don't see a big disadvantage handling timezone-calculations in Java itself.
In message <l0t0ynlpptf2$....@kimmeringer.de>, Lothar Kimmeringer wrote:
> Lawrence D'Oliveiro wrote:
>> In message <iretd3$lg...@dont-email.me>, Daniele Futtorovic wrote:
>>> The JRE carries regularly updated timezone info (which can be updated >>> independently of the JRE) for the purpose of running in environments >>> that do not sport a perfectly serviceable set of timezone informations.
>> Which is not the case with Linux. Why can it not use zoneinfo when it’s >> available?
> Because these files are part of the runtime-classes which are > Java and are therefor platform independent.
Is that like saying you can never take the plane from an airport in your town, because other towns don’t have airports?
> BTW: How is Linux ensuring that the timezone-files are staying correct?
Much more easily and quickly than any software vendor can provide software patches.
For example, Chile recently rushed through a bill to extend its daylight- saving hours, just days before the period was due to end under the old rules. A zoneinfo patch was available that same week <http://article.gmane.org/gmane.comp.time.tz/3702>, and has already been rolled into the regular release <ftp://elsie.nci.nih.gov/pub/>.
> In message<l0t0ynlpptf2$....@kimmeringer.de>, Lothar Kimmeringer wrote:
>> Lawrence D'Oliveiro wrote:
>>> In message<iretd3$lg...@dont-email.me>, Daniele Futtorovic wrote:
>>>> The JRE carries regularly updated timezone info (which can be updated >>>> independently of the JRE) for the purpose of running in environments >>>> that do not sport a perfectly serviceable set of timezone informations.
>>> Which is not the case with Linux. Why can it not use zoneinfo when it’s >>> available?
>> Because these files are part of the runtime-classes which are >> Java and are therefor platform independent.
> Is that like saying you can never take the plane from an airport in your > town, because other towns don’t have airports?
>> BTW: How is Linux ensuring that the timezone-files are staying correct?
> Much more easily and quickly than any software vendor can provide software > patches.
> For example, Chile recently rushed through a bill to extend its daylight- > saving hours, just days before the period was due to end under the old > rules. A zoneinfo patch was available that same week > <http://article.gmane.org/gmane.comp.time.tz/3702>, and has already been > rolled into the regular release<ftp://elsie.nci.nih.gov/pub/>.
> Has Java been patched for this yet?
Yes, as you would know if you did even the most minimal checking.
In message <irg8gm$ib...@localhost.localdomain>, Martin Gregorie wrote:
> [rubbish]
Interesting how not a single one of you has addressed the relevant point. Let me repeat it:
For example, Chile recently rushed through a bill to extend its daylight- saving hours, just days before the period was due to end under the old rules. A zoneinfo patch was available that same week <http://article.gmane.org/gmane.comp.time.tz/3702>, and has already been rolled into the regular release <ftp://elsie.nci.nih.gov/pub/>.
On 05/24/2011 08:04 PM, Lawrence D'Oliveiro wrote:
> In message<irg8gm$ib...@localhost.localdomain>, Martin Gregorie wrote:
>> [rubbish]
> Interesting how not a single one of you has addressed the relevant point. > Let me repeat it:
> For example, Chile recently rushed through a bill to extend its daylight- > saving hours, just days before the period was due to end under the old > rules. A zoneinfo patch was available that same week > <http://article.gmane.org/gmane.comp.time.tz/3702>, and has already been > rolled into the regular release<ftp://elsie.nci.nih.gov/pub/>.
On Mon, 23 May 2011 07:38:54 -0700 (PDT), loial <jldunn2...@gmail.com> wrote, quoted or indirectly quoted someone who said :
>Do I need to do something different in Java 1.6?.
read the release notes for the two versions and those in between to see the corrections made to timezone data. Timezones are as goofy as the spellings of female babies. It is big job to keep track of all the eccentricities.
The later version will be the more correct. -- Roedy Green Canadian Mind Products http://mindprod.com How long did it take after the car was invented before owners understood cars would not work unless you regularly changed the oil and the tires? We have gone 33 years and still it is rare to uncover a user who understands computers don't work without regular backups.
Wed, 25 May 2011 12:04:30 +1200, /Lawrence D'Oliveiro/:
> For example, Chile recently rushed through a bill to extend its daylight- > saving hours, just days before the period was due to end under the old > rules. A zoneinfo patch was available that same week > <http://article.gmane.org/gmane.comp.time.tz/3702>, and has already been > rolled into the regular release <ftp://elsie.nci.nih.gov/pub/>.
> Has Java been patched for this yet?
Java has a TZupdater (Timezone Updater) tool which takes care:
In message <iri87l$no...@dont-email.me>, Stanimir Stamenkov wrote:
> Wed, 25 May 2011 12:04:30 +1200, /Lawrence D'Oliveiro/:
>> For example, Chile recently rushed through a bill to extend its daylight- >> saving hours, just days before the period was due to end under the old >> rules. A zoneinfo patch was available that same week >> <http://article.gmane.org/gmane.comp.time.tz/3702>, and has already been >> rolled into the regular release <ftp://elsie.nci.nih.gov/pub/>.
>> Has Java been patched for this yet?
> Java has a TZupdater (Timezone Updater) tool which takes care:
So the answer is “no”: you need to download, install and run a separate tool to apply a patch to fix it up.
The first one is a diff. What does it do? Why, just look at the diff itself, and you can see what it does. No hidden surprises there; it’s not even code, it’s just data, i.e. timezone rules. How to apply it? Just use patch(1), a standard utility available on all self-respecting open-source-based systems.
What’s the second one? It’s a .jar file with a readme. What does it do? Don’t know for sure, actually. The readme says one thing, but without source code to refer to, how can you be sure?
How do you roll out that Oracle patch? You have to double-click it or something on every single system where you want to install it. Do you have to reboot or something afterwards? To be safe, probably yes.
How do you roll out the tzdata patch? That’s easy: you can run a bulk SSH loop across all your systems.
