FULL PRODUCT VERSION :
java version "1.5.0_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05)
Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Windows XP 2002 SP2 32-bit on Intel P4

EXTRA RELEVANT SYSTEM CONFIGURATION :
My PC is configured in the UK with the Windows Date and Time as follows:

(GMT) Greenwich Mean Time : Dublin, Edinburgh, Lisbon, London
[ticked] Automatically adjust clock for daylight saving changes


A DESCRIPTION OF THE PROBLEM :
Throughout this report I refer to the tickbox "Automatically adjust clock for daylight saving changes" in the Windows Date and Time settings dialog.

My PC has the standard configuration for the UK.  In other words: GMT with the tickbox for automatic daylight savings TICKED.

It is now winter, so the tickbox should have no effect on my time zone, nor should it affect formatting of dates.

There are two problems.  First, the tickbox results in a different time zone in winter.  This may or may not be intended functionality, doesn't bother me, but may shed some light on the problem.

Secondly, the main problem, is the value zero UTC (value as passed into the "new Date(long)" constructor) is shown as a *different time* when formatted using Date.toString() - depending on whether you have this tickbox ticked or unticked.

When I have the tickbox TICKED (this is how my system is normally configured) my test program outputs:

sun.util.calendar.ZoneInfo[id="Europe/London",offset=0,dstSavings=3600000,useDaylight=true,transitions=242,lastRule=java.util.SimpleTimeZone[i
d=Europe/London,offset=0,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=3600000,startTimeMo
de=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]]
Current offset (minutes): 0
Zero UTC represented as... Thu Jan 01 01:00:00 GMT 1970

I don't understand how current offset can be zero, yet Zero UTC is represented as 1 hour later.

When I have this tickbox UNTICKED, I get:

D:\iokio\bonsai>java -cp "..\Bonsai buildtemp\extrabin" TimeZoneTest
Current zone: sun.util.calendar.ZoneInfo[id="GMT",offset=0,dstSavings=0,useDaylight=false,transitions=0,lastRule=null]
Current offset (minutes): 0
Zero UTC represented as... Thu Jan 01 00:00:00 GMT 1970

Here Zero UTC is formatted correctly and the time zone is entirely different.

Unfortunately, if I leave this box ticked, all my dates are internally 1 hour out.  But if I leave it unticked, they will be wrong come summer.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Try my sample code under Java 1.4.2_07 or Java 1.5.0_05, first with the Windows XP "Automatically adjust clock for daylight saving changes" ticked, then with it unticked, both times with GMT dublin/edinburgh etc. timezone selected.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I expect to see the same timezone, or at least zero UTC being formatted as 00:00:00 Jan 1 1970, regardless of the state of this tickbox.
ACTUAL -
With it ticked, date.toString() is one hour out which is incorrect in winter.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.util.Date;
import java.util.TimeZone;

public class TimeZoneTest
{
    
    public static void main(String[] args) {
        TimeZone zone = TimeZone.getDefault();
        System.err.println("Current zone: "+zone);
        System.err.println("Current offset (minutes): "
            +zone.getRawOffset()/60000);
        System.err.println("Zero UTC represented as... "+new Date(0));
        System.exit(0);
    }
    
}

---------- END SOURCE ----------