OS2 World.Com Forum

Subject  :  eCS Changes to Support new 2007 U.S. Daylight Saving Time DST Rules
Author  :  ghelfrich ghelfrich919@yahoo.com
Date  :  07 Feb, 2007 on 21:09
I have not seen or heard any word on any eCS fix or changes that should be done in advance of the new 2007 U.S. Daylight Saving Time DST Rules taking affect next month. Does anyone know what should be done? Does it require a change to the the TZ definition in config.sys? Is there a change to the eCS clock instead? I can always wait for DST to occur and just change the system time, but this would have to be done twice a year then.

Has anyone heard anything, or know what should be done in advance? Thanks.

Gerry Helfrich


Subject  :  Re:eCS Changes to Support new 2007 U.S. Daylight Saving Time DST Rules
Author  :  El Vato
Date  :  07 Feb, 2007 on 23:41
Please, see below:

Subject  :  Re:eCS Changes to Support new 2007 U.S. Daylight Saving Time DST Rules
Author  :  El Vato
Date  :  07 Feb, 2007 on 23:49

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.



Subject  :  Re:eCS Changes to Support new 2007 U.S. Daylight Saving Time DST Rules
Author  :  melf mikaelelf@os2ug.se
Date  :  08 Feb, 2007 on 19:52
eCS Maintance tool has an eclock update, was that what youwere looking for? Look at attached screendump.

---
/Mikael

Subject  :  Re:eCS Changes to Support new 2007 U.S. Daylight Saving Time DST Rules
Author  :  ghelfrich ghelfrich919@yahoo.com
Date  :  08 Feb, 2007 on 21:46
First, thanks to both both El Vato and Mikael for your responses.

Do either of you know if one or the either is necessary, or both ...? For example, if I download the maintenance fix to the eCS clock, do I need to change the TZ string in config.sys? Or do I need to do it only if it has DST rules in it? I am trying to figure out the dependency between the two.

Also, is the updated eCS clock included in the eCS v2 beta 3 release, which I am also running?

Once again, thanks again in advance for any help / info provided.

Gerry Helfrich


Subject  :  Re:eCS Changes to Support new 2007 U.S. Daylight Saving Time DST Rules
Author  :  melf mikaelelf@os2ug.se
Date  :  09 Feb, 2007 on 08:33
I think this update is very fresh and not included in beta 3.
The other question is to technical for me, I guess el Vato knows.

---
/Mikael

Subject  :  Re:eCS Changes to Support new 2007 U.S. Daylight Saving Time DST Rules
Author  :  El Vato
Date  :  09 Feb, 2007 on 12:31

ghelfrich (08 Feb, 2007 21:46):
[...]

Do either of you know if one or the either is necessary, or both ...?


It is an exclusive OR proposition. That is, select either one but NOT both (however, read on for special conditions). A word of caution: BACK UP your CONFIG.SYS before you do either.

As far as I am concerned, ANY version of OS/2 that supports the TZ variable in CONFIG.SYS will benefit from the procedure described priorly by GCD. Accordingly, unless eCS has successfully implemented another Time Zone variable, the above procedure is also applicable.

Apparently the eClock fix is a utility to hide the manual implementation of the TZ settings (including DST) from the user --hence decreasing the possibility of error on his/her part (however if your time zone is not includded you still need to know about TZ to manually add your time zone: < http://www.os2voice.org/VNL/past_issues/VNL0803H/vnewsf4.htm >);

As an aside, an "enhanced" OS/2 version is not available to the regular OS/2 user (on purpose) unless s/he begs for it:

< http://www.ecomstation.com/news.phtml?action=fullnews&showcomments=1&id=161 >

Evidently, this organization lives in the past. It does not even realize that development would be accelerated if this tiny sort of utilities were allowed to be modified freely by creative OS/2 hackers under an variant open source licenses.

[...]


ghelfrich (08 Feb, 2007 21:46):
Gerry Helfrich

Best of luck !


Powered by UltraBoard 2000 <www.ub2k.com>