TZSet sets the time zone from the TZ environment variable.
Program is distributed as ZIP package: download to temporary directory and unpack to destination folder. See below for download link(s).
Following ones are the download links for manual installation:
TZSet v. 1.1 (29/7/2024, Peter Moylan) | Readme/What's new |
CHANGE RECORD
Version 1.1 (29 Jul 2024)
Different default values for summer start/end, in the
case where CLOCK.INI can't be read, so that TZset.exe
doesn't exit immediately.
Fixed: the source files for TZset.exe were accidentally
omitted in the last release.
Updated installation section of manual to stress the
fact that Clock.exe must be run at least once.
Fixed: in Danish, one tab was incorrectly labelled.
Added TZonce.exe to the distribution. |
ftp.pmoylan.org/software/TZSet_1.1.zip | ||
TZSet v. 1.0 (8/10/2020, Peter Moylan) | Readme/What's new |
CHANGE RECORD
Version 1.0 ( 8 Oct 2020)
New version numbering sequence.
Major redesign to separate the user interface from
the daemon that waits for a time zone change
to happen. (See manual.) |
ftp.pmoylan.org/software/TZSet_1.0.zip | ||
TZSet v. 09 (2/1/2019, Peter Moylan) | Readme/What's new |
CHANGE RECORD
Version 09
Fixed: crash when the TZ string contained a negative
"seconds after midnight" value.
Updated TZOnce to show the next time zone changes in
the future, rather than in the current year.
Tidied up source code to make it more readable. |
ftp.pmoylan.org/software/tzset09.zip | ||
TZSet v. 08 (1/10/2017, Peter Moylan) | Readme/What's new |
CHANGE RECORD
Version 08
Removed a duplicate "Summer time ends" message.
Version 07
Changed the "US default rules" to reflect changes to the
summer time start and end dates for those states that
respect the federal standard.
Fixed: start/end dates for the following year were
incorrect. Those dates were relevant for any case
where the summer is already over.
Display change: the screen output messages use more
human-friendly date formats than the internal format.
Display change: we don't display the minutes until the
next change unless it is really close. Before that we
display hours or days, as appropriate.
Added an icon. |
ftp.pmoylan.org/software/Older/tzset08.zip | ||
TZSet v. 07 (6/6/2017, Peter Moylan) | Readme/What's new |
CHANGE RECORD
Version 07
Changed the "US default rules" to reflect changes to the
summer time start and end dates for those states that
respect the federal standard.
Fixed: start/end dates for the following year were
incorrect. Those dates were relevant for any case
where the summer is already over.
Display change: the screen output messages use more
human-friendly date formats than the internal format.
Display change: we don't display the minutes until the
next change unless it is really close. Before that we
display hours or days, as appropriate.
Added an icon.
|
ftp.pmoylan.org/software/Older/tzset07.zip | ||
TZSet v. 06 (23/4/2015, Peter Moylan) | ||
ftp.pmoylan.org/software/Older/tzset06.zip | ||
TZSet v. 05A (16/4/2014, Peter Moylan) | ||
ftp.pmoylan.org/software/Older/tzset05A.zip | ||
TZSet v. 05 (10/4/2014, Peter Moylan) | ||
ftp.pmoylan.org/software/Older/tzset05.zip | ||
TZSet v. 04 (9/4/2014, Peter Moylan) | ||
ftp.pmoylan.org/software/Older/tzset04.zip | ||
TZSet v. 03 (2/11/2008, Peter Moylan) | Readme/What's new |
TZSet: set the time zone from the TZ environment variable
---------------------------------------------------------
Current version: 03 Last update: 03 Apr 2002
Author: Peter Moylan
---------------------------------------------------------
This program is freeware. To the best of my knowledge it
works correctly, but it comes with no guarantees.
WHAT IS IT?
One of the very strange omissions in OS/2 is any provision
for setting your time zone as part of the system settings.
OS/2 applications programmers who have had to use the
procedure DosGetDateTime will have discovered that there is
a time zone offset included in the result, but that this
field is always reported as -1 (meaning "undefined").
As a result, programmers have adopted the habit of ignoring
this field. A program that needs to know the time zone will
do one of two things:
(a) Copy the Unix solution of requiring a TZ variable to
be defined as an environment string. This works, but
it means that each such program has to decode a
string that has a rather cryptic format. That adds to
the size of each such program.
(b) Include something in its own user interface that lets
users specify their time zone. This works, too,
but it's unnecessary duplication. If you have several
such programs, you have to set the time zone once for
each program, rather than using one central setting.
The TZSet program is my contribution to reducing all this
duplication. In the short term it doesn't reduce any
duplication, because only my own applications get the benefit.
In the longer term, I'm hoping that other applications
developers can be encouraged to use the timezone information
supplied by DosGetDateTime.
Ideally, what I'd like to do is to add an extra page to
the Properties notebook of the "System Clock" object, but
I haven't yet had the courage to tackle that job. (And
maybe I never will - I dislike developing PM applications.)
What I've done, instead, is to write a program that sets
the system time zone offset by decoding the TZ environment
variable.
The result of running this program is to set the "time zone
offset" value in the information record used by DosGetDateTime.
That means that future calls to DosGetDateTime will return
a record that includes the time zone offset.
Unfortunately this information does not survive a shutdown
and reboot. You can get around this by running TZSet as
part of your startup operations, for example by including a
shadow or program object in the Startup folder.
SETTING UP THE TZ ENVIRONMENT VARIABLE
Depending on what software you already have installed, you
might already have a TZ environment variable. To check,
type
SET TZ
at an OS/2 command prompt. The result should be a line like
TZ=EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600
If you get this sort of result, you can skip the rest of
this section. (For North American locations only, you can
expect to have a much shorter TZ string.) Otherwise, you
need to define the TZ variable. You could do this manually,
by editing your CONFIG.SYS to include a suitable definition,
but this is error-prone (and it requires you to know the
meaning of each parameter in the TZ string).
A far simpler method is to get hold of a freeware program
called TZCALC, available from the usual OS/2 archive sites.
(If you already have TIME868, by the same author, then you
probably already have a copy of TZCALC, because it was
included in version F of TIME868.) This is a utility to
calculate the correct TZ string for your location. It
includes prerecorded settings for a great many locations
around the world.
(And here I'd like to record my thanks to Norbert Dey, the
author of TIME868 and TZCALC. These programs definitely
belong in any "best of OS/2" collection.)
After you've worked out what the string should be, edit
your CONFIG.SYS to include the line
SET TZ=the appropriate value
This change won't take effect until your next reboot.
If you're eager to run TZSet before your next reboot, you
can type the same SET command at an OS/2 command prompt
- of course, setting TZ that way will be effective only
for the duration of that particular command-line session.
RUNNING TZSet
TZSet doesn't take any parameters. All you have to do
is type
TZSet
at a command prompt, and the job is done.
Unfortunately the information stored by TZSet is lost
when you shut down your computer, so you need to re-run
the program each time you re-boot. The easiest ways
to do this are to put a shadow or program object for TZSet.EXE
in your Startup folder, or to run TZSet from STARTUP.CMD. |
ftp.pmoylan.org/software/Older/tzset03.zip |
This work is licensed under a Creative Commons Attribution 4.0 International License.
Add new comment