Timezones and versions of Java
loial
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.
--
Nigel Wade
loial
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
>
> 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
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.
--
Lew
RTFM.
Lawrence D'Oliveiro
<fde67e7a-6198-4e7f...@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?
Daniele Futtorovic
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"
Lawrence D'Oliveiro
> 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?
Lothar Kimmeringer
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: spam...@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)
Always remember: The answer is forty-two, there can only be wrong
questions!
Lawrence D'Oliveiro
> 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?
Lew
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
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.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
Lothar Kimmeringer
> In message <l0t0ynlpptf2$.d...@kimmeringer.de>, Lothar Kimmeringer wrote:
>>
>> 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?
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.
Lawrence D'Oliveiro
> [rubbish]
Interesting how not a single one of you has addressed the relevant point.
Let me repeat it:
Lawrence D'Oliveiro
> Lawrence D'Oliveiro wrote:
>
>> In message <l0t0ynlpptf2$.d...@kimmeringer.de>, Lothar Kimmeringer wrote:
>>>
>>> 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?
>
> 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
Again, asked and answered. Yes.
Roedy Green
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.
Stanimir Stamenkov
> 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
Lawrence D'Oliveiro
> 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?
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>.
Nigel Wade
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
bugbear
For a supposedly experienced programmer, Lawrence
finds a lot of simple tasks surprisingly difficult.
BugBear
Stanimir Stamenkov
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
Steve Sobol
> So the answer is ?no?: you need to download, install and run a separate tool
> to apply a patch to fix it up.
Funny. At times I've had to do EXACTLYY THE SAME THING to update TZ data
in the operating system.
Windows and Linux, both.
> How many people are going to bother with this?
People who want their clock to be correct.
--
Steve Sobol - Programming/WebDev/IT Support
sjs...@JustThe.net
Lawrence D'Oliveiro
> In article <iric9v$l95$1...@lust.ihug.co.nz>, Lawrence D'Oliveiro says...
>
>> So the answer is “no”: you need to download, install and run a separate
>> tool to apply a patch to fix it up.
>
> Funny. At times I've had to do EXACTLYY THE SAME THING to update TZ data
> in the operating system.
Compare the difference: this
<http://article.gmane.org/gmane.comp.time.tz/3702> versus this
<http://download.oracle.com/otn-pub/java/tzupdater/1.3.38/tzupdater-1_3_38-2011e.zip>
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.
Lew
"No true Scotsman", Lawrence.
Lawrence D'Oliveiro
> 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.
Lew
> 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?
Where'd you get "willy-nilly"? No one said that. You don't get to add that
straw man and then treat it like Stanimir said it, Lawrence! Shame on you,
Lawrence!
> 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.
Still pulling your "No True Scotsman" bullshit, Lawrence.
First you said no one but Java needs a patch. Then it was shown that, for
example, Linux needs a patch. Then you started making up stuff about the Java
patch. And who says the Java patch is a code patch? Obviously it patches
something in the bootstrap JAR world, but is it code? Have you checked?
It's been shown time and again that your argument here is full of shit, so you
keep changing the terms of your argument. That's classic "No True Scotsman"
baloney, there, Lawrence, old boy.
So how about you stop that crap? I've seen you make valid, well-reasoned
points before, so how about you make a habit of it, hm, Lawrence, old bean?
That's a good boy.