Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Timezones and versions of Java

Reply
Thread Tools

Timezones and versions of Java

 
 
loial
Guest
Posts: n/a
 
      05-23-2011
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);



}

}
 
Reply With Quote
 
 
 
 
Nigel Wade
Guest
Posts: n/a
 
      05-23-2011
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

 
Reply With Quote
 
 
 
 
loial
Guest
Posts: n/a
 
      05-23-2011
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 <(E-Mail Removed)> 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


 
Reply With Quote
 
Nigel Wade
Guest
Posts: n/a
 
      05-23-2011
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


 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      05-23-2011
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.
 
Reply With Quote
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      05-23-2011
In message
<(E-Mail Removed)>, 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?
 
Reply With Quote
 
Daniele Futtorovic
Guest
Posts: n/a
 
      05-24-2011
On 24/05/2011 01:50, Lawrence D'Oliveiro allegedly wrote:
> In message
> <(E-Mail Removed)>, 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"
 
Reply With Quote
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      05-24-2011
In message <iretd3$lgu$(E-Mail Removed)>, 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?
 
Reply With Quote
 
Lothar Kimmeringer
Guest
Posts: n/a
 
      05-24-2011
Lawrence D'Oliveiro wrote:

> In message <iretd3$lgu$(E-Mail Removed)>, 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 its
> 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: http://www.velocityreviews.com/forums/(E-Mail Removed)
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
 
Reply With Quote
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      05-24-2011
In message <l0t0ynlpptf2$(E-Mail Removed)>, Lothar Kimmeringer wrote:

> Lawrence D'Oliveiro wrote:
>
>> In message <iretd3$lgu$(E-Mail Removed)>, 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?
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Supporting Joda timezones in non-Java applications. jasonc Java 5 03-03-2009 02:36 AM
ASP.NET AJAX Date serialization and timezones =?Utf-8?B?U3R1?= ASP .Net 7 04-18-2007 09:06 AM
timezones and time_t MrBlueSky Python 2 08-19-2006 09:20 PM
Help with DateTime and TimeZones / DayLight savings time Ryan Ternier ASP .Net 1 10-14-2005 05:20 PM
log4j and Timezones - help! sarah.wilson@cpp.co.uk Java 2 02-11-2005 09:22 AM



Advertisments