Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #4453 > unrolled thread

Timezones and versions of Java

Back to article view | Back to comp.lang.java.programmer

Contents

  Timezones and versions of Java loial <jldunn2000@gmail.com> - 2011-05-23 07:38 -0700
    Re: Timezones and versions of Java Nigel Wade <nmw-news@ion.le.ac.uk> - 2011-05-23 15:45 +0100
      Re: Timezones and versions of Java loial <jldunn2000@gmail.com> - 2011-05-23 08:12 -0700
    Re: Timezones and versions of Java Nigel Wade <nmw-news@ion.le.ac.uk> - 2011-05-23 16:26 +0100
    Re: Timezones and versions of Java Lew <noone@lewscanon.com> - 2011-05-23 11:58 -0400
    Re: Timezones and versions of Java Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-24 11:50 +1200
      Re: Timezones and versions of Java Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-24 02:16 +0200
        Re: Timezones and versions of Java Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-24 14:40 +1200
          Re: Timezones and versions of Java Lothar Kimmeringer <news200709@kimmeringer.de> - 2011-05-24 09:12 +0200
            Re: Timezones and versions of Java Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-24 20:25 +1200
              Re: Timezones and versions of Java Lew <noone@lewscanon.com> - 2011-05-24 08:14 -0400
                Re: Timezones and versions of Java bugbear <bugbear@trim_papermule.co.uk_trim> - 2011-05-25 09:55 +0100
              Re: Timezones and versions of Java Martin Gregorie <martin@address-in-sig.invalid> - 2011-05-24 12:32 +0000
                Re: Timezones and versions of Java Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-25 12:04 +1200
                  Re: Timezones and versions of Java Lew <noone@lewscanon.com> - 2011-05-24 21:57 -0400
                  Re: Timezones and versions of Java Stanimir Stamenkov <s7an10@netscape.net> - 2011-05-25 09:39 +0300
                    Re: Timezones and versions of Java Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-25 19:49 +1200
                      Re: Timezones and versions of Java Nigel Wade <nmw-news@ion.le.ac.uk> - 2011-05-25 09:35 +0100
                      Re: Timezones and versions of Java Stanimir Stamenkov <s7an10@netscape.net> - 2011-05-25 14:55 +0300
                        Re: Timezones and versions of Java Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-27 13:09 +1200
                          Re: Timezones and versions of Java Lew <noone@lewscanon.com> - 2011-05-26 22:11 -0400
                      Re: Timezones and versions of Java Steve Sobol <sjsobol@JustThe.net> - 2011-05-25 09:35 -0700
                        Re: Timezones and versions of Java Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-26 11:34 +1200
                          Re: Timezones and versions of Java Lew <noone@lewscanon.com> - 2011-05-25 21:50 -0400
                    Re: Timezones and versions of Java Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-25 19:50 +1200
              Re: Timezones and versions of Java Lothar Kimmeringer <news200709@kimmeringer.de> - 2011-05-24 17:26 +0200
                Re: Timezones and versions of Java Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-25 12:07 +1200
    Re: Timezones and versions of Java Roedy Green <see_website@mindprod.com.invalid> - 2011-05-24 19:34 -0700

Page 1 of 2  [1] 2  Next page →

#4453 — 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);



   }

}

[toc] | [next] | [standalone]

#4454

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

[toc] | [prev] | [next] | [standalone]

#4456

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

[toc] | [prev] | [next] | [standalone]

#4457

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

[toc] | [prev] | [next] | [standalone]

#4464

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.

[toc] | [prev] | [next] | [standalone]

#4501

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?

[toc] | [prev] | [next] | [standalone]

#4502

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"

[toc] | [prev] | [next] | [standalone]

#4509

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?

[toc] | [prev] | [next] | [standalone]

#4515

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!

[toc] | [prev] | [next] | [standalone]

#4519

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?

[toc] | [prev] | [next] | [standalone]

#4526

On 05/24/2011 04:25 AM, Lawrence D'Oliveiro wrote:
> 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?

Yes, as you would know if you did even the most minimal checking.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#4566

Lew wrote:
> On 05/24/2011 04:25 AM, Lawrence D'Oliveiro wrote:
>> In message<l0t0ynlpptf2$.dlg@kimmeringer.de>, Lothar Kimmeringer wrote:
>>
>>> Lawrence D'Oliveiro wrote:
>>
>> Has Java been patched for this yet?
>
> Yes, as you would know if you did even the most minimal checking.
>

For a supposedly experienced programmer, Lawrence
finds a lot of simple tasks surprisingly difficult.

  BugBear

[toc] | [prev] | [next] | [standalone]

#4530

On Tue, 24 May 2011 20:25:01 +1200, Lawrence D'Oliveiro wrote:

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


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#4551

In message <irg8gm$ibj$2@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/>.

Has Java been patched for this yet?

[toc] | [prev] | [next] | [standalone]

#4558

On 05/24/2011 08:04 PM, Lawrence D'Oliveiro wrote:
> In message<irg8gm$ibj$2@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/>.
>
> Has Java been patched for this yet?

Again, asked and answered.  Yes.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#4561

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

-- 
Stanimir

[toc] | [prev] | [next] | [standalone]

#4562

In message <iri87l$no8$1@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.

How many people are going to bother with this?

[toc] | [prev] | [next] | [standalone]

#4564

On 25/05/11 08:49, Lawrence D'Oliveiro wrote yet more complete and utter
rubbish:
> In message <iri87l$no8$1@dont-email.me>, Stanimir Stamenkov wrote:
> 
>>> Has Java been patched for this yet?
>>
>> Java has a TZupdater (Timezone Updater) tool which takes care:
> 

[moronic utterings deleted]

Why do you bother continuing to feed this troll?

-- 
Nigel Wade

[toc] | [prev] | [next] | [standalone]

#4569

Wed, 25 May 2011 19:49:18 +1200, /Lawrence D'Oliveiro/:
> In message <iri87l$no8$1@dont-email.me>, Stanimir Stamenkov wrote:
> 
>> 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?

People who care or need it, people maintaining servers.  Those who 
don't need it will get the latest data with the next JRE update.

-- 
Stanimir

[toc] | [prev] | [next] | [standalone]

#4623

In message <iriqn9$tt8$1@dont-email.me>, Stanimir Stamenkov wrote:

> Wed, 25 May 2011 19:49:18 +1200, /Lawrence D'Oliveiro/:
>
>> In message <iri87l$no8$1@dont-email.me>, Stanimir Stamenkov wrote:
>> 
>>> 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?
> 
> People who care or need it, people maintaining servers.

Production servers? Are you really going to roll out a code patch willy-
nilly across all your production systems?

The problem is, why does Java need a CODE patch to apply a DATA update? The 
tzdata patch I referenced is just a data patch, no changes to any code at 
all. That’s why folks like Debian feel safe classifying such updates as 
“volatile”, being immediately applicable even to production systems running 
“stable” installations.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web