TZSet

Version: 
1.1
Release date: 
Wednesday, 2 January, 2019

License:

Interface:

Authors/Port authors:

TZSet sets the time zone from the TZ environment variable.

This software is distributed as compressed package. You have to download and manually install it; if prerequisites are required, you will have to manually install them too.

Manual installation

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
Record updated last time on: 31/07/2024 - 06:02

Translate to...

Add new comment