El Vato (07 Feb, 2007 23:41):
Noting that Java from Golden Code Development (GCD) might have an issue with the DST, I contacted them for advice sometime ago. It appears that the information provided by GCD is relevant to your inquiry --because the Time Zone (TZ) variable applies to the operating system in general. As opposed to the Sun fix for their Java implementations (< http://java.sun.com/javase/downloads/index.jsp >), GCD's recommended workaround is to set the "fix" at the operating system level by setting the TZ variable appropriately in OS/2's CONFIG.SYS.
Below is the relevant information to help you resolve your issue:
"However,
this problem can be solved by setting your TZ environment variable in
CONFIG.SYS as follows (from the readme):
-----------------------------------------------------------------------------
9. Timezone Processing
The GCD JVM defaults to GMT if the TZ environment variable is not set.
If the TZ variable is set properly, there should not be any issues with
timezone processing. However, if the daylight savings time values are
not encoded in the TZ variable and the defaults for your timezone are
not acceptable, you will need to set the TZ environment variable using
the format below. More importantly the GCD JVM is dependent upon the
IBM VisualAge C++ CRT library. This library has been shown to yield
inconsistent results in some cases, unless the TZ environment variable
is fully specified. Once encoded properly, this will be detected and
will
override the defaults. IF YOU FIND ANY PROBLEMS, MAKE SURE TO FULLY
ENCODE YOUR DST INFORMATION INTO THE TZ ENVIRONMENT VARIABLE.
To include DST information, use the following format (much of the
TZ format information comes from the IBM VisualAge C++ documentation):
SET TZ=<SSS>[[-|+]h[:m[:s]]][DDD][,sm,sw,sd,st,em,ew,ed,et,shift]
Where:
<SSS> Standard-timezone identifier. It must be
three characters, must begin with a
letter,
and can contain spaces.
[-|+] Optional sign which indicates the
direction
of offset from GMT. + is west of GMT and -
is east.
[h[:m[:s]]] Optional difference in hours) between the
standard time zone and GMT. Minutes and
seconds can also be optionally specified.
[DDD] Optional daylight saving time (DST) zone
identifier. It must be three characters,
must
begin with a letter, and can contain
spaces.
sm Starting month (1 to 12) of DST.
sw Starting week (-4 to 4) of DST. Use
negative
numbers to count back from the last week
of
the month (-1) and positive numbers to
count
from the first week (1).
sd Starting day of DST.
0 to 6 if sw != 0
1 to 31 if sw = 0
st Starting time (in seconds) of DST.
em Ending month (1 to 12) of DST.
ew Ending week (-4 to 4) of DST. Use
negative
numbers to count back from the last week
of
the month (-1) and positive numbers to
count from the first week (1).
ed Ending day of DST.
0 to 6 if ew != 0
1 to 31 if ew = 0
et Ending time of DST (in seconds).
shift Amount of time change (in seconds).
If you give values for any of sm, sw, sd, st, em, ew, ed, et, or shift,
you
must give values for all of them. If any are missing, the entire
statement
is considered not valid, and the time zone information is not changed.
In order to limit the possible impact of these known problems in the
IBM CRT
library, the JVM will attempt to detect if the TZ environment variable
has
sufficient DST definitions. When the JVM detects that the DST
indicator is
missing, it will add the DST indicators for popular timezones, based on
this
list:
TZ Default DST Indicator
----- -------------------------------
EST ",4,1,0,3600,10,-1,0,7200,3600"
CST ",4,1,0,3600,10,-1,0,7200,3600"
MST ",4,1,0,3600,10,-1,0,7200,3600"
PST ",4,1,0,3600,10,-1,0,7200,3600"
HST "" (no DST indicator)
CET ",3,-1,0,7200,10,-1,0,7200,3600"
MEZ ",3,-1,0,7200,10,-1,0,7200,3600"
MET ",3,-1,0,7200,10,-1,0,7200,3600"
WET ",3,-1,0,3600,10,-1,0,3600,3600"
EET ",3,-1,0,3600,10,-1,0,3600,3600"
BST ",3,-1,0,3600,10,-1,0,3600,3600"
IST ",3,-1,0,3600,10,-1,0,3600,3600"
This ensures that there are reasonable defaults for well known
timezones. It
also allows for full configuration control by the user through the
normal
TZ environment variable.
If there are other appropriate timezone codes in use that aren't in the
above
table, the user should be sure to include it in their TZ environment
variable.
Customers with a support contract can specify updates to this list and
GCD will
provide these at no additional charge. At the current time these
defaults are
not user-configurable.
----------------------------------------------------------------------------- "
Additionally, and the issue is of extreme importance for us as a way to keep up with current Java technology trends, GCD mentions that the company has no issues developing another native Java implementaion for OS/2 EXCEPT that the OS/2 licensee base is quite small.
In other words, and this is my take on the issue, NOT supporting GCD's effort in developing native Java implementaions for OS/2 has effectively diminished their interest in another Java port to our side.
It appears, after all, that selecting Innotek's Odin layered WinXX hack over the superb GCD native OS/2 implementation, has had a negative effect on the organization's seriousness.