-
Bug
-
Resolution: Duplicate
-
P4
-
None
-
1.1.8
-
x86
-
windows_nt
Name: md23716 Date: 05/25/2000
On Win NT 1.1.8 JDK, Sun have implemented a cut-down version of the matching of
NT time zones to Java time zones from 1.2.2 JDK.
One quirk of this implementation is that a number of the European countries which
are at GMT +2 are mapped to Africa/Cairo timezone, which has different daylight
savings rules - the particular customer in this case is in Finland.
This has happened specifically because 'FLE Standard Time' isn't in the list
of timezones mapped by name (in the source file locale_str.h), so instead the
offset from GMT is used, without the locale ID (which is the difference from 1.2.2
where the locale ID is used). This means that only one set of daylight savings
rules can be applied for each offset from GMT.
So, for GMT +2 with daylight savings, 'EET' is selected as the timezone to be used,
from the timezone map table in file timezone_map.h, and the user.timezone
system property is set to this.
And then something strange happens : when TimeZone.getDefault() is called by the
Java program, the 'EET' system property is mapped to 'Africa/Cairo' in the idMap
table, which then maps to the 'ART' simple timezone (this all happens in TimeZone.java).
Either somebody got confused, or a conscious decision has been made to give ART
preference over Eastern Europe, in which case we'll need to inform our customer that this
is a specific limitation of Java 1.1.
static public void main( String[] args )
{
//-------------------------------------------------------------
// Get a default TimeZone object that we can play with. The
// TimeZOne class cannot be instantiated by itself.
//-------------------------------------------------------------
TimeZone tz = TimeZone.getDefault() ;
//--------------------------------------------------------------
// Query which time zone we are currently in.
//
//--------------------------------------------------------------
System.out.println( "Our current time zone is " + tz.getID() ) ;
//--------------------------------------------------------------
// This test will check to see if the time zone that we are
// currently in uses daylight savings time at all.
//--------------------------------------------------------------
if ( tz.useDaylightTime() )
{
System.out.println( "Current time zone uses daylight savings time." ) ;
}
else
{
System.out.println( "Current time zone does not use daylight savings time." ) ;
}
//------------------------------------------------------------
// This test will see if the time zone we are in is currently
// Using daylight savings time.
//------------------------------------------------------------
if ( tz.inDaylightTime( new Date() ) )
{
System.out.println( "Current time zone is in daylight savings time now." ) ;
}
else
{
System.out.println( "Current time zone is not in daylight savings time now." ) ;
}
}
Set up NTs date& time so that the machine is in GMT +2 Helsinki (for example), and the
timezone will be reported as 'ART' ; daylight savings will use the Africa/Cairo rules
(ie GMT +3 from last Friday in April to last Friday in september) rather than the Europe/Helsinki
rules (GMT +3 from last Sunday in March to last Sunday in October, same as Europe/Istanbul).
(Review ID: 105315)
======================================================================
- duplicates
-
JDK-4252829 Win32: platform-to-java timezone mapping has errors; mapping tables are obsolete
-
- Resolved
-