Discrepancy in current hour

[Rhino]

Just out of curiosity, if you put, just after the declaration of
'expectedHour', the line

   Calendar calinst = Calendar.getInstance()
   int calendarHour = calinst.get( Calendar.HOUR );

what does it give you?

While we're at it, what do

   calinst.getTimeZone.getDisplayName()
and
   calinst.getTimeZone.getOffset( calinst.getTimeInMillis() )

return?

After changing the expected result to one hour later than it actually
is, I amended the test case as follows:

-----------------------------------
public void testGetCurrentHour12() {

//TODO: why does this method return 9 (PM) when it is actually 8 in
this time zone right now?
int currentHour = dateTimeUtils.getCurrentHour12HourClock();
int expectedHour = 12;
assertTrue("The actual hour (12 hour clock), " + currentHour + ",
does not equal the expected hour, " + expectedHour,
currentHour==expectedHour); //$NON-NLS-1$ //$NON-NLS-2$
Calendar calinst = Calendar.getInstance();
int calendarHour = calinst.get( Calendar.HOUR );
System.out.println("calendarHour: " + calendarHour);
System.out.println("calinst.getTimeZone().getDisplayName() is: " +
calinst.getTimeZone().getDisplayName());

System.out.println("calinst.getTimeZone().getOffset(calinst.getTimeInMillis())
is: " + calinst.getTimeZone().getOffset( calinst.getTimeInMillis() ));
}

-----------------------------------

The result from executing it is:

-----------------------------------
calendarHour: 0
calinst.getTimeZone().getDisplayName() is: Eastern Standard Time
calinst.getTimeZone().getOffset(calinst.getTimeInMillis()) is:
-14400000
-----------------------------------

I wonder why you write a utility method to get the current hour when the
standard API already provides a one-line way to do so.

I must have missed that way in the standard API. Can you remind what
it is? I'm not sure which class you're thinking of....

 

[Rhino]

I've been purely a Linux user for the last 8 years, so the last Windows
version I understand in any depth is Win95. I still have it installed for
the rare occasions when I need to run a couple of programs I haven't yet
tried to run under Wine. That box dual-boots, so I am very familiar with
local-clock Win95 and UTC Linux fighting over the RTC. My only experience
of a more recent Window was a three month contract writing Java with
IntelliJ on an XP box, which I treated as a black box platform since
testing, etc. was done under RHEL.

This is why I posed the questions I'd want to look into rather than
giving you answers.

Fair enough. I'll obviously need to follow up with the MIcrosoft
newsgroup once we've confirmed that it is in fact as OS issue, not a
Java one.

Maybe they can tell me why DST fixing pages don't actually work.....

Thanks!

 

[Rhino]

Okay, I see your point now. (Well, actually it was Eric's point and
you are clarifying it.) But I'm not clear on what I have to do
differently. How do I know the object has finished construction so
that I know it is safe to use it? In other words, how should I code it
differently.

[ SNIP ]

Section 12.5 of the Java Language Specification (JLS) discusses creation
of new class instances, but for your purposes what it boils down to is
that the last things to execute before you get a finished ready-to-go
object are the statements in the body of your constructor (excepting
this() and super() statements, which occur earlier). IOW, when you leave
the body of the constructor is when you've got your finished object.

IOW, where your code 'main()' now has 'new TestHour()', it would have instead
something similar to

   TestHour th = new TestHour();
   th.showResults();

or simply

   new TestHour().showResults();

Okay, I'm starting to get this. But what work would be done in the
constructor and what are you envisioning taking place in
showResults()?

I'm trying to keep everything simple since that is what the first 'S'
in SSCCE stands for ;-) Remember, I've had to copy my real code out of
DateTimeUtils and simplify it a bit for the purposes of the example.
(The key change was that I use resource bundles to look up a localized
error message in the real code; here, I just display a paraphrase of
the error message since the error message is unrelated to the
problem.)

The real DateTimeUtils has the same methods (aside from the
localization stuff) but has private constructors and public
getInstance() methods so it's not the same as TestHour in that way.

 

[Lew]

I must have missed that way in the standard API. Can you remind what
it is? I'm not sure which class you're thinking of....

It's in the code samples you provided in your original question:

All I did differently was to follow Eric Sosman's advice for "the recommended
`Calendar.getInstance()'".

Note that if you don't need to re-use the calendar instance, you can get the
current hour in a single line:

int calendarHour = Calendar.getInstance().get( Calendar.HOUR );

 

[Rhino]

It's in the code samples you provided in your original question:


All I did differently was to follow Eric Sosman's advice for "the recommended
`Calendar.getInstance()'".

Note that if you don't need to re-use the calendar instance, you can get the
current hour in a single line:

  int calendarHour = Calendar.getInstance().get( Calendar.HOUR );

Okay, I'm getting a little dizzy here. First, I was doing everything
with Calendar and was told that it would be better to use DateFormat
and SimpleDateFormat so I rewrote the methods to use that approach
(after having to review a bit to figure out how to use them.) Now
you're telling me that the original way was fine?

Just for the heck of it, I wrote a little display method to get all
the values that are available from Calendar:

public void useCalendar() {

System.out.println("The AM_PM is: " +
Calendar.getInstance().get(Calendar.AM_PM));
System.out.println("The DATE is: " +
Calendar.getInstance().get(Calendar.DATE));
System.out.println("The DAY_OF_MONTH is: " +
Calendar.getInstance().get(Calendar.DAY_OF_MONTH));
System.out.println("The DAY_OF_WEEK_IN_MONTH is: " +
Calendar.getInstance().get(Calendar.DAY_OF_WEEK_IN_MONTH));
System.out.println("The DAY_OF_YEAR is: " +
Calendar.getInstance().get(Calendar.DAY_OF_YEAR));
System.out.println("The DST_OFFSET is: " +
Calendar.getInstance().get(Calendar.DST_OFFSET));
System.out.println("The ERA is: " +
Calendar.getInstance().get(Calendar.ERA));
System.out.println("The HOUR is: " +
Calendar.getInstance().get(Calendar.HOUR));
System.out.println("The HOUR_OF_DAY is: " +
Calendar.getInstance().get(Calendar.HOUR_OF_DAY));
System.out.println("The MILLISECOND is: " +
Calendar.getInstance().get(Calendar.MILLISECOND));
System.out.println("The MINUTE is: " +
Calendar.getInstance().get(Calendar.MINUTE));
System.out.println("The MONTH is: " +
Calendar.getInstance().get(Calendar.MONTH));
System.out.println("The SECOND is: " +
Calendar.getInstance().get(Calendar.SECOND));
System.out.println("The WEEK_OF_MONTH is: " +
Calendar.getInstance().get(Calendar.WEEK_OF_MONTH));
System.out.println("The WEEK_OF_YEAR is: " +
Calendar.getInstance().get(Calendar.WEEK_OF_YEAR));
System.out.println("The YEAR is: " +
Calendar.getInstance().get(Calendar.YEAR));
System.out.println("The ZONE_OFFSET is: " +
Calendar.getInstance().get(Calendar.ZONE_OFFSET));
}

The results (I ran this just AFTER midnight):

------------------------------------------------------------------
The AM_PM is: 0
The DATE is: 21
The DAY_OF_MONTH is: 21
The DAY_OF_WEEK_IN_MONTH is: 3
The DAY_OF_YEAR is: 80
The DST_OFFSET is: 3600000
The ERA is: 1
The HOUR is: 1
The HOUR_OF_DAY is: 1
The MILLISECOND is: 328
The MINUTE is: 14
The MONTH is: 2
The SECOND is: 46
The WEEK_OF_MONTH is: 4
The WEEK_OF_YEAR is: 13
The YEAR is: 2010
The ZONE_OFFSET is: -18000000

------------------------------------------------------------------

I'm not sure if those results help you at all....

For what it's worth, some of my methods are just getting parts of the
date and like hour and year but others are doing other things, like
ensuring that a given date fits a given format or producing a given
date component as a String rather than an int. I wrote these several
years back but I don't remember why I coded them all the way I did.

I am happy to learn more about Java and improve my code but getting
told to do it one way, spending time to do it, then being told to
change it all back to the way it was is frustrating to say the least.
I'm just trying to be obliging here and accept what I'm being told
rather than make everyone justify their advice. I'm assuming you guys
know more than me. Maybe I have to start getting a little more
assertive and make you justify the changes you are asking me to
make....

In any case, I _DO_ appreciate the help I am getting, even if it is a
little frustrating at times.

Does anyone see anything yet that makes them think this is _NOT_ an OS
issue? For that matter, has anyone tried this code on their own
machines? Did any of you get the same problem I'm getting with the
hour being one hour later than it should be?

 

[Lew]

Okay, I'm starting to get this. But what work would be done in the
constructor and what are you envisioning taking place in
showResults()?

'showResults()' would be all the code you wrote to show the results of your
actions, i.e., those 'println()' and related calls you showed us.

The constructor, well, constructs the object - initializes the state to
usability. Often it's nothing more than allocating memory, in which case one
can often simply rely on the default constructor and put all the meat into the
methods. Anything not related to constructing an instance and making it ready
for use really doesn't (usually) belong in a constructor.

The real DateTimeUtils has the same methods (aside from the
localization stuff) but has private constructors and public
getInstance() methods so it's not the same as TestHour in that way.

The question isn't whether the constructor is private, but whether the calls
to those methods occur within it.

 

[Lew]

I am happy to learn more about Java and improve my code but getting
told to do it one way, spending time to do it, then being told to
change it all back to the way it was is frustrating to say the least.

No one told you to "change it all back to the way it was". You presented a
whole bunch of complicated code at one point that was dragging out integers
from Calendar fields and padding them with characters into Strings. All that
messy conversion seemed better suited to use of DateFormat. As a separate
question, I asked why you were wrapping a simple call to
Calendar.get(Calendar.HOUR), a small piece of the overall stringification
process only. Separate issue, and a question, not advice.

I'm just trying to be obliging here and accept what I'm being told
rather than make everyone justify their advice. I'm assuming you guys
know more than me. Maybe I have to start getting a little more
assertive and make you justify the changes you are asking me to
make....

How about distinguishing between advice ("Try X") and a request for
information ("Why Y?"). The latter assumes you have a reason for doing
something that the questioner has interest in knowing.

An example of advice:

Or use java.text.DateFormat / SimpleDateFormat.
<http://java.sun.com/javase/6/docs/api/java/text/DateFormat.html>
<http://java.sun.com/javase/6/docs/api/java/text/SimpleDateFormat.html>

Those related to providing String representations.

An example of a request for information:

I wonder why you write a utility method to get the current hour
when the standard API already provides a one-line way to do so.

Advice there would have been redundant since you were already using the
technique in the body of your utility method, so clearly you knew of it. It
was just one programmer looking to find out what another programmer's
reasoning was.

"Get the current hour" is a different task from "provide a String
representation of a Calendar instance". Advice appropriate to one task might
not apply to the other.

 

[Rhino]

No one told you to "change it all back to the way it was".  You presented a
whole bunch of complicated code at one point that was dragging out integers
from Calendar fields and padding them with characters into Strings.  All that
messy conversion seemed better suited to use of DateFormat.  As a separate
question, I asked why you were wrapping a simple call to
Calendar.get(Calendar.HOUR), a small piece of the overall stringification
process only.  Separate issue, and a question, not advice.

I'm starting to see what was meant now. You were reacting to my little
home-grown pad() method that put leading zeroes on the date components
when needed and then turned the whole thing into a String. And ONLY
that. I thought the advice I was getting was that ALL of the code was
crap and should all be redone to use DateFormat and SimpleDateFormat.
This ordeal has already dragged on long enough so I just decided to
take it on faith that DateFormat and SimpleDateFormat were "better"
somehow and not question it in the interests of time. (I might have
asked about it somewhere down the road.)

And again, when you mentioned using Calendar again, I thought you were
saying that Calendar was better after all and now all the code should
be based on Calendar instead of DateFormat/SimpleDateFormat.

I'm not going to point fingers here and blame this on you or the
others who are trying to help. I'll just chalk it up to an honest
misunderstanding. Like I said, I'm not stupid but I'm not a psychic
either. And neither are any of you. We all know what we had in mind
when we wrote what we wrote but we can't know how the other guy is
going to take it.

How about distinguishing between advice ("Try X") and a request for
information ("Why Y?").  The latter assumes you have a reason for doing
something that the questioner has interest in knowing.

An example of advice:




Those related to providing String representations.

An example of a request for information:


Advice there would have been redundant since you were already using the
technique in the body of your utility method, so clearly you knew of it.  It
was just one programmer looking to find out what another programmer's
reasoning was.

"Get the current hour" is a different task from "provide a String
representation of a Calendar instance".  Advice appropriate to one task might
not apply to the other.

Fair enough.

Now back to the question at hand. Do you see anything here that makes
you think the Java code is wrong in some way? I'm still leaning
strongly to the OS as being the culprit but I don't want to start
pestering the Windows experts until I can say that we have looked over
the Java code thoroughly and are satisfied that this IS an OS issue.
Otherwise, I'm going to bouncing back and forth like a frigging
pingpong ball between Windows and Java experts.....

 

[Arved Sandstrom]

'showResults()' would be all the code you wrote to show the results of
your actions, i.e., those 'println()' and related calls you showed us.

The constructor, well, constructs the object - initializes the state to
usability. Often it's nothing more than allocating memory, in which
case one can often simply rely on the default constructor and put all
the meat into the methods. Anything not related to constructing an
instance and making it ready for use really doesn't (usually) belong in
a constructor.

[ SNIP ]

To add to this, the constructor will ensure that the member fields of
the object are either initialized to the values you've supplied as ctor
arguments (so this initialization will rely on statements you've written
in the ctor body), or to default values, or as set by instance variable
initializers or instance initializers.

AHS

 

[Rhino]

I'm starting to see what was meant now. You were reacting to my little
home-grown pad() method that put leading zeroes on the date components
when needed and then turned the whole thing into a String. And ONLY
that. I thought the advice I was getting was that ALL of the code was
crap and should all be redone to use DateFormat and SimpleDateFormat.
This ordeal has already dragged on long enough so I just decided to
take it on faith that DateFormat and SimpleDateFormat were "better"
somehow and not question it in the interests of time. (I might have
asked about it somewhere down the road.)

And again, when you mentioned using Calendar again, I thought you were
saying that Calendar was better after all and now all the code should
be based on Calendar instead of DateFormat/SimpleDateFormat.

I'm not going to point fingers here and blame this on you or the
others who are trying to help. I'll just chalk it up to an honest
misunderstanding. Like I said, I'm not stupid but I'm not a psychic
either. And neither are any of you. We all know what we had in mind
when we wrote what we wrote but we can't know how the other guy is
going to take it.











Fair enough.

Now back to the question at hand. Do you see anything here that makes
you think the Java code is wrong in some way? I'm still leaning
strongly to the OS as being the culprit but I don't want to start
pestering the Windows experts until I can say that we have looked over
the Java code thoroughly and are satisfied that this IS an OS issue.
Otherwise, I'm going to bouncing back and forth like a frigging
pingpong ball between Windows and Java experts.....

Just to bring everything up to date, I have made the recommended
changes in the Java code.

1. I amended the getCurrentTime() method to use SimpleDateFormat.
2. I reverted the getCurrentHour methods to use GregorianCalendar.
3. I changed TestHour and TestHour2 so that they start like this:

------------------------------------------------------
public class TestHour {

final static boolean DEBUG = true;

public static void main(String[] args) {

TestHour testHour = new TestHour();
testHour.showResults();
}

public TestHour() {

//empty
}

public void showResults() {

System.out.println("The current hour on the 12 hour clock is: " +
getCurrentHour12HourClock() + ".\n");
System.out.println("The current hour on the 24 hour clock is: " +
getCurrentHour24HourClock() + ".\n");
System.out.println("The current time is: " + getCurrentTime() + ".
\n");
}
//date/time methods omitted
}

------------------------------------------------------

When I run the tests again now, the results still show the hour being
one hour too late.

I'm going out of town now for a couple of days and won't be able to
get online to check this thread until late Monday night. I look
forward to seeing more helpful suggestions on my problem - and,
ideally, a final verdict on whether the problem is with Java or the OS
- on my return.

Thanks again for all the help!

 

[Rhino]

'showResults()' would be all the code you wrote to show the results of
your actions, i.e., those 'println()' and related calls you showed us.

The constructor, well, constructs the object - initializes the state to
usability.  Often it's nothing more than allocating memory, in which
case one can often simply rely on the default constructor and put all
the meat into the methods.  Anything not related to constructing an
instance and making it ready for use really doesn't (usually) belong in
a constructor.

[ SNIP ]

To add to this, the constructor will ensure that the member fields of
the object are either initialized to the values you've supplied as ctor
arguments (so this initialization will rely on statements you've written
in the ctor body), or to default values, or as set by instance variable
initializers or instance initializers.

That all makes sense. And it's a good lesson to me too. Sometimes, I
see code in examples in the newsgroup or elsewhere online and imitate
them without fully understanding what they are doing. I think I must
have seen something like:

new TestHour();

used in a fragment once, noticed that it was more concise than:

TestHour testHour = new TestHour();

and saw that the former was more concise than the latter, and just
assumed it was exactly equivalent. That assumption turns out to be
wrong as I've learned in this thread and now I know why. I can stay
away from that approach and modify any other code that does that in
"real" programs, as opposed to SSCCEs.

Thanks all for explaining this point to me!

 

[Eric Sosman]

[...]
5) Refrain from calling non-final instance methods on objects
that haven't finished construction! This is a Big No-No;
don't do it!

[...]
With regards to your fifth point, I'm afraid I still get a little
muddled when someone makes a generalized commment like that without
also pointing to the specific thing I've done wrong. Can you clarify
which object hasn't finished construction?

Think, Rhino, think! Think about the life cycle of an
object instance! Do you remember the sequence of events?

1) The JVM allocates memory for the object's fields and
clears it all to zero (actually, the moment at which
the zeroing occurs isn't specified, but it happens
somewhere before Step 2)

2) The JVM calls the object's constructor, which calls
its superclass constructor, ..., which calls the
constructor of java.lang.Object.

4) The Object constructor initializes the Object aspects
of the new memory, then returns to the next constructor
which initializes the Whatnot aspects, then returns ...,
to the class' own constructor, which initializes the
MostSpecific aspects of the object.

5) The most specific constructor returns, and *now* at last
the construction of the object is complete.

Now, can you spot any moment in this scenario where the
object exists (sort of) but has not been fully constructed?
Can you say what code is running at that moment? Does this
narrow your search any?

Answer: Gur GrfgUbhe bowrpg unf abg orra pbafgehpgrq hagvy
gur GrfgUbhe pbafgehpgbe ergheaf (abg rira gura, vs vg'f npghnyyl
n GrfgUbhe fhopynff gung'f haqre pbafgehpgvba). Lrg gur GrfgUbhe
pbafgehpgbe pnyyf bireevqnoyr vafgnapr zrgubqf. Frr Oybpu
"Rssrpgvir Wnin," Vgrz 15.

 

[Lew]

That all makes sense. And it's a good lesson to me too. Sometimes, I
see code in examples in the newsgroup or elsewhere online and imitate
them without fully understanding what they are doing. I think I must
have seen something like:

new TestHour();

used in a fragment once, noticed that it was more concise than:

TestHour testHour = new TestHour();

and saw that the former was more concise than the latter, and just
assumed it was exactly equivalent. That assumption turns out to be
wrong as I've learned in this thread and now I know why. I can stay
away from that approach and modify any other code that does that in
"real" programs, as opposed to SSCCEs.

The only difference between the two is that the first discards the reference
and the second assigns it to a variable.

If one does not need to reuse the reference, the first form is fine:

new TestHour().doSomething();

If one needs to reuse the reference, the second form is required:

TestHour testHour = new TestHour();
testHour.doSomething();
testHour.doSomethingElse();

 

[Lew]

Answer: Gur GrfgUbhe bowrpg unf abg orra pbafgehpgrq hagvy
gur GrfgUbhe pbafgehpgbe ergheaf (abg rira gura, vs vg'f npghnyyl
n GrfgUbhe fhopynff gung'f haqre pbafgehpgvba). Lrg gur GrfgUbhe

In a manner of speaking, the 'TestHour' object *has* been completely
constructed after its completion, even if part of a subclass's construction.
It's the subclass instance that has not been completely constructed.

To be more precise, it's the 'TestHour' part of the overall object that has
been completely constructed when the 'TestHour' part of construction completes.

 

[Eric Sosman]

In a manner of speaking, the 'TestHour' object *has* been completely
constructed after its completion, even if part of a subclass's
construction. It's the subclass instance that has not been completely
constructed.

... except that if a subclass is being constructed, the object
is not fully constructed when a superclass constructor finishes.
The object is a SubTestHour, which "is a" TestHour only in the sense
that it can stand in for a TestHour in any code that wants to use
a TestHour. Still, the .getClass() method returns SubTestHour.class,
not TestHour.class.

To be more precise, it's the 'TestHour' part of the overall object that
has been completely constructed when the 'TestHour' part of construction
completes.

... and if the TestHour constructor calls an overridable method,
and SubTestHour overrides that method, what is the status of the
SubTestHour object when the method is called from TestHour's
constructor, hmmm?

class Super {
private final int value;
Super() {
value = 42;
showValue(); // DON'T DO THIS!!!
}
void showValue() {
System.out.println("Super value = " + value);
}
public static void main(String[] unused) {
new Sub();
}
}

class Sub extends Super {
private final String value;
Sub() {
value = "forty-two";
showValue(); // DON'T DO THIS!!!
}
void showValue() {
System.out.println("Sub value = " + value);
}
}

(If you don't see what's wrong, do two things: First,
predict the output, and second, compile and run the code.)

 

[Lew]

... except that if a subclass is being constructed, the object
is not fully constructed when a superclass constructor finishes.

"The object" being the subclass instance. I was discussing only that
*portion* of the object for which the superclass constructor is responsible,
hence the "in a manner of speaking".

The object is a SubTestHour, which "is a" TestHour only in the sense
that it can stand in for a TestHour in any code that wants to use
a TestHour. Still, the .getClass() method returns SubTestHour.class,
not TestHour.class.

... and if the TestHour constructor calls an overridable method,
and SubTestHour overrides that method, what is the status of the
SubTestHour object when the method is called from TestHour's
constructor, hmmm?

Indeed, that is the danger in calling overridable methods before the
constructor (in this case, the superclass constructor) is finished.

class Super {
private final int value;
Super() {
value = 42;
showValue(); // DON'T DO THIS!!!

At this point, the 'Super' part of any subclass instance is not yet fully
constructed.

}
void showValue() {
System.out.println("Super value = " + value);
}
public static void main(String[] unused) {
new Sub();
}
}

class Sub extends Super {
private final String value;
Sub() {
value = "forty-two";
showValue(); // DON'T DO THIS!!!
}
void showValue() {
System.out.println("Sub value = " + value);
}
}

(If you don't see what's wrong, do two things: First,
predict the output, and second, compile and run the code.)

Excellent exegesis, Eric.

Regardless of "manner of speaking", it is dangerous to use an instance before
it's fully constructed, super, sub and barrel.

 

[Eric Sosman]

[...]
Regardless of "manner of speaking", it is dangerous to use an instance
before it's fully constructed, super, sub and barrel.

Slight topic branch: One of the unpleasant consequences is
that it's unsafe for a constructor to publish a `this' reference.
When I was a Javanewbie I sometimes wrote classes that maintained
collections of all their instances, thus (genericized for current
audiences, although generics weren't around in my newbie days):

class Wotsit {
private static final Set<Wotsit> universe
= new HashSet<Wotsit>();
Wotsit(...) {
...
universe.add(this);
}
...
}

I later learned that this is a Bad Thing, because if another
thread traverses the contents of `universe' it could come across
a Wotsit (or Wotsit subclass) that wasn't yet fully operational.

The only way I know of to maintain such a collection safely
is to hide the constructor and make folks use a factory method:

class Dingbat {
private static final Set<Dingbat> universe
= new HashSet<Dingbat>();
private Dingbat(...) {
...
}
static Dingbat newInstance(...) {
Dingbat edith = new Dingbat(...);
universe.add(edith);
return edith;
}
...
}

This has the unfortunate side-effect that Dingbat cannot be
subclassed, because of the private constructor. Yet if you
make the constructor anything other than private, there's a
risk that someone will do `new Dingbat()' and `universe' will
be incomplete.

How do others deal with this? Give up on "all instances"
collections? Live with effectively-final classes? Document
the living daylights out of it and hope for the best? Or is
there something niftier that can be done?

 

[Dr J R Stockton]

So are we to conclude, as you have not stated it, that the time you
checked was actually 1:37 p.m. Eastern Daylight, and that you are in
the Eastern time zone?


That is not correct, if you are in the Eastern Time Zone and DST is in
effect. If you are in the Eastern Time Zone and DST is in effect, you
are at GMT-04:00.

-5:00 is a correct label for the zone containing Ottawa. Time Zones
govern winter Time, and do not change seasonally. An extra hour or so
may be added for Summer Time.

 

[sgmentzer]

I'm just retesting some date/time methods I wrote a while back and
noticed something odd. It's 8 PM Eastern time as I write this and the
date routines I have just retested tell me that it's actually 9 PM. Why
would that be?

I just happened to install Windows XP Pro and SP3 on an old laptop to
run a Java app and noticed this problem too.

It's an issue with XP. The US Daylight Savings Time begin/edit dates
are pre-2007. At the bottom of the Adjust Date dialog it shows the
current timezone, which should be Eastern Daylight Time, but instead
shows Eastern Standard Time.

I don't know why the latest service pack didn't update the timezone
data, but here we are. Microsoft offers a timezone editing tool to fix
it yourself:

http://download.microsoft.com/download/5/8/a/58a208b7-7dc7-4bc7-8357-28e29cdac52f/tzedit.exe

US DST rule is here http://wwp.greenwichmeantime.com/time-zone/rules/usa.htm

Note: I had to click Update Now on the Internet Time tab of the clock
dialog to force this change (even after reboot). Maybe just changing
the time would have worked too, or maybe I was impatient and it would
have made the correction on its own.

Steve

 

[Rhino]

I just happened to install Windows XP Pro and SP3 on an old laptop to
run a Java app and noticed this problem too.

It's an issue with XP. The US Daylight Savings Time begin/edit dates
are pre-2007. At the bottom of the Adjust Date dialog it shows the
current timezone, which should be Eastern Daylight Time, but instead
shows Eastern Standard Time.

I don't know why the latest service pack didn't update the timezone
data, but here we are. Microsoft offers a timezone editing tool to fix
it yourself:

http://download.microsoft.com/download/5/8/a/58a208b7-7dc7-4bc7-8357-...

US DST rule is herehttp://wwp.greenwichmeantime.com/time-zone/rules/usa.htm

Note: I had to click Update Now on the Internet Time tab of the clock
dialog to force this change (even after reboot). Maybe just changing
the time would have worked too, or maybe I was impatient and it would
have made the correction on its own.

Steve

You've nailed it Steve! I ran the program you suggested, TZEdit, and
adjusted the start and end dates for EST appropriately and now my OS
shows the correct time AND Java is displaying the correct hour too!

Many thanks!!!!

All's well that ends well: I have the time problem sorted out and I've
learned several useful things about Java that I've been able to
incorporate into my Java code.

Thanks again to all who participated in this thread.