Parsing dates and daylight savings time

[Paul J. Lucas]

Given:

SimpleDateFormat df = new SimpleDateFormat( "yyyy:MM:dd HH:mm:ss" );
String s = "2007:02:04 19:29:50";
Date d = df.parse( s );

what I want to happen is that, since the date format does not contain a
timezone, I want it to be taken to be in the host's local timezone. I am in the
Pacific timezone with daylight savings time in effect. Yet when I print d using
Date.toString(), I get:

Sun Feb 04 19:29:50 PST 2007

Why is it PST? It should be PDT. The result of:

TimeZone.getDefault().useDaylightTime()

is true. How do I fix this so that daylight savings time is correctly taken
into account?

- Paul

 

[Lew]

Given:

        SimpleDateFormat df = new SimpleDateFormat( "yyyy:MM:dd HH:mm:ss" );
        String s = "2007:02:04 19:29:50";
        Date d = df.parse( s );

what I want to happen is that, since the date format does not contain a
timezone, I want it to be taken to be in the host's local timezone.  I am in the
Pacific timezone with daylight savings time in effect.  Yet when I print d using
Date.toString(), I get:

        Sun Feb 04 19:29:50 PST 2007

Why is it PST?  It should be PDT.  The result of:

        TimeZone.getDefault().useDaylightTime()

is true.  How do I fix this so that daylight savings time is correctly taken
into account?

February 4 in the Pacific time zone is within Standard Time, not
Daylight Saving Time. It is already correct.

<http://en.wikipedia.org/wiki/
Daylight_saving_time_around_the_world#From_2007_on>
"DST started on the second Sunday of March"

 

[John B. Matthews]

[...]

Just a guess, but perhaps SimpleDateFormat bases its ST/DT
decision on what it thinks was in effect not quite a year ago, not
on the state of affairs "now."

[...]

Good point. My desktop vendor provided an update back then, but I recall
having to track down an updater for several other servers:

<http://java.sun.com/javase/timezones/>

 

[Lew]

     Just a guess, but perhaps SimpleDateFormat bases its ST/DT
decision on what it thinks was in effect not quite a year ago, not
on the state of affairs "now."  Since Standard Time is in effect

But "now" being January, Pacific Time is still Standard Time.

for dates in February (in the USA), it may be that SimpleDateFormat
says "Hmmm: no zone and offset specified, I guess I'll use what
the rest of the country was using that day."

That is the behavior, and it's correct. Not "what the rest of the
country was using that day", but what the time zone of the host was
using that day.

The host running the program was in Pacific time, and the February
date was in Standard Time, so it showed as being in PST, and would
even if parsed in June from that time zone.

 

[Eric Sosman]

But "now" being January, Pacific Time is still Standard Time.

Yes, but he said he's running "with daylight savings in
effect." I don't know exactly how he "effected" that, but I
took him at his word: His system is in PDT even though all
its neighbors are in PST.

 

[Lew]

     Yes, but he said he's running "with daylight savings in
effect."  I don't know exactly how he "effected" that, but I
took him at his word: His system is in PDT even though all
its neighbors are in PST.

He also said, "How do I fix this so that daylight savings time is
correctly taken
into account?" He can't be correct and running in Pacific Daylight
Time in January (or February) simultaneously.

 

[Paul J. Lucas]

He also said, "How do I fix this so that daylight savings time is
correctly taken
into account?" He can't be correct and running in Pacific Daylight
Time in January (or February) simultaneously.

Uhm, OK, I had a "senior moment" and flipped daylight/standard time in my head.
I'm currently running in *standard* time and the date is correct. Never mind.

- Paul