Timezones and versions of Java

[loial]

I am trying to convert BST times to EST.

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
BST time Tue May 04 12:48:18 2010


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

Platform is linux.






class testtz {
public static void main(String[] args) {


Date date = null;

SimpleDateFormat dateFormat = new
SimpleDateFormat("yyyyMMddHHmmss");

try {

date = dateFormat.parse("20100504124818");
}
catch(ParseException pe) {
System.out.println("Error");
}

TimeZone tz1 = TimeZone.getDefault();

long localOffset = tz1.getOffset(date.getTime());

System.out.println("Local Offset " + localOffset);

TimeZone tz2 = TimeZone.getTimeZone("EST");

long remoteOffset = tz2.getOffset(date.getTime());

System.out.println("EST Offset " + remoteOffset);


Date dateToPutInDB = new Date(date.getTime() - localOffset +
remoteOffse;


System.out.println("EST time " + dateToPutInDB)

System.out.println("BST time " + date);



}

}

 

[Nigel Wade]

I am trying to convert BST times to EST.

The following code correctly returns a difference of 5 hours between
the 2 times when run under Java 1.5. :

Not it doesn't, it doesn't even compile. Post the actual code you are
running.

 

[loial]

import java.util.*;
import java.text.*;
class testtz {
public static void main(String[] args) {


Date date = null;


SimpleDateFormat dateFormat = new
SimpleDateFormat("yyyyMMddHHmmss");


try {


date = dateFormat.parse("20100504124818");
}
catch(ParseException pe) {
System.out.println("Error");
}


TimeZone tz1 = TimeZone.getDefault();


long localOffset = tz1.getOffset(date.getTime());


System.out.println("Local Offset " + localOffset);


TimeZone tz2 = TimeZone.getTimeZone("EST");


long remoteOffset = tz2.getOffset(date.getTime());


System.out.println("EST Offset " + remoteOffset);


Date dateToPutInDB = new Date(date.getTime() - localOffset +
remoteOffset);


System.out.println("EST time " + dateToPutInDB);


System.out.println("BST time " + date);


}

}

 

[Nigel Wade]

I am trying to convert BST times to EST.

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
BST time Tue May 04 12:48:18 2010

That time difference is wrong.

However if run under Java 1.6 (on the same machine), it returns a time
difference of 6 hours :

BST is 1 hour ahead of GMT, EST is 5 hours behind GMT. That's a total of
6 hours. (Note: EST does not implement DST, that is EDT).

 

[Lew]

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.

}
catch(ParseException pe) {
System.out.println("Error");
}

TimeZone tz1 = TimeZone.getDefault();

If you're in the Northern Hemisphere in most jurisdictions, you will not get
"EST" from this on May 4.

long localOffset = tz1.getOffset(date.getTime());

System.out.println("Local Offset " + localOffset);

TimeZone tz2 = TimeZone.getTimeZone("EST");

long remoteOffset = tz2.getOffset(date.getTime());

System.out.println("EST Offset " + remoteOffset);


Date dateToPutInDB = new Date(date.getTime() - localOffset +
remoteOffse;


System.out.println("EST time " + dateToPutInDB)

System.out.println("BST time " + date);



}

}

<http://download.oracle.com/javase/6/docs/api/java/util/TimeZone.html>
"Three-letter time zone IDs

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

Have you considered reading the documentation?

RTFM.
RTFM.
RTFM.

 

[Lawrence D'Oliveiro]

In message

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?

 

[Daniele Futtorovic]

In message


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.

 

[Lawrence D'Oliveiro]

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?

 

[Lothar Kimmeringer]

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.


Regards, Lothar
--
Lothar Kimmeringer E-Mail: (e-mail address removed)
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!

 

[Lawrence D'Oliveiro]

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?

 

[Lew]

Is that like saying you can never take the plane from an airport in your
town, because other towns don’t have airports?


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.

 

[Martin Gregorie]

Is that like saying you can never take the plane from an airport in your
town, because other towns don’t have airports?

No.

 

[Lothar Kimmeringer]

Is that like saying you can never take the plane from an airport in your
town, because other towns don¢t have airports?

No, it's more like saying, that I prefer wearing my own watch even
if I reside in an area where you can see public clocks very often.


Regards, Lothar
--
Lothar Kimmeringer E-Mail: (e-mail address removed)
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!

 

[Lawrence D'Oliveiro]

[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/>.

Has Java been patched for this yet?

 

[Lawrence D'Oliveiro]

No, it's more like saying, that I prefer wearing my own watch even
if I reside in an area where you can see public clocks very often.

No, it’s more like saying you aren’t allowed to use the public clock, you
must go by my watch.

Java isn’t giving you the choice of whether to be stupid or clever, it’s
forcing you to always be stupid.

 

[Lew]

[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/>.

Has Java been patched for this yet?

Again, asked and answered. Yes.

 

[Roedy Green]

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.

 

[Stanimir Stamenkov]

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:

http://www.oracle.com/technetwork/java/javase/downloads/index-jsp-138363.html#timezone

http://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html

http://www.oracle.com/technetwork/java/javase/timezones-137583.html

and yes the exact update you're mentioning seems to be there:

http://www.oracle.com/technetwork/java/javase/tzdata-versions-138805.html

That's what Lew has referred to with "you would know if you did even
the most minimal checking".

 

[Lawrence D'Oliveiro]

Wed, 25 May 2011 12:04:30 +1200, /Lawrence D'Oliveiro/:


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.

How many people are going to bother with this?

 

[Lawrence D'Oliveiro]

Java has a TZupdater (Timezone Updater) tool which takes care:

Actually the link (bypassing the licence-agreement page) is here
<http://download.oracle.com/otn-pub/java/tzupdater/1.3.38/tzupdater-1_3_38-2011e.zip>.