Timezones and versions of Java
 

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);



}

}

Re: Timezones and versions of Java
 

On 23/05/11 15:38, loial wrote:
> 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.

--
Nigel Wade

Re: Timezones and versions of Java
 

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);


}

}







On May 23, 3:45*pm, Nigel Wade <nmw-n...@ion.le.ac.uk> wrote:
> On 23/05/11 15:38, loial wrote:
>
> > 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.
>
> --
> Nigel Wade

Re: Timezones and versions of Java
 

On 23/05/11 15:38, loial wrote:
> 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).

> Local Offset 3600000
> EST Offset -18000000
> EST time Tue May 04 06:48:18 2010
> BST time Tue May 04 12:48:18 2010
>
>


--
Nigel Wade

Re: Timezones and versions of Java
 

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.

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

--
Lew
RTFM.

Re: Timezones and versions of Java
 

In message
<fde67e7a-6198-4e7f-a07b-4655c1108d15@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?

Re: Timezones and versions of Java
 

On 24/05/2011 01:50, Lawrence D'Oliveiro allegedly wrote:
> In message
> <fde67e7a-6198-4e7f-a07b-4655c1108d15@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"

Re: Timezones and versions of Java
 

In message <iretd3$lgu$1@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?

Re: Timezones and versions of Java
 

Lawrence D'Oliveiro wrote:

> In message <iretd3$lgu$1@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.


Regards, Lothar
--
Lothar Kimmeringer E-Mail: spamfang@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

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

Re: Timezones and versions of Java
 

In message <l0t0ynlpptf2$.dlg@kimmeringer.de>, Lothar Kimmeringer wrote:

> Lawrence D'Oliveiro wrote:
>
>> In message <iretd3$lgu$1@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?