Handling different Time Zones

, ,
1

We have been tasked with finding the best way to have our international users see the system time displayed in their local time. (these same users also want batch reports to reflect their time)

We know about the TD parameter but we are trying to find the best way to associate time differential with a user.

I’d like to find out how companies are doing this and figure out which is the best solution for us. If you are doing something like this, what time do you use to store your data in? and how do you handle displaying audit dates and times on various screens?

Thank you
Belinda Tinsley
Thomas & Betts Corporation
Memphis, TN 38135

NAT 4.14
ADA 7.4.4
PRD 4.4.1
Z/OS 1.4

2

Belinda,

I think I saw this same question on SAG-L yesterday. If it was not you posting it then you might want to look there for additional info.

As for your question: the only way I have experienced this done is by establishing a user’s location as part of their log on. This works so long as you don’t have too many road hogs traveling the country. The particular company was a railroad that spaned all US timezones and had reportings done and displayed in local time with conversions done to a ‘standard’ time - in their case Central - before comparisons and calculations such as journey time were done. System reportings used *TIMX which was central and was then converted to suite the reporting station.

A physical and a reporting station were part of a user profile and each station was assigned a timezone in the station file.

3

The mainframe allows the TD parameter to be set as TD=‘USA-EST’ (see http://techcommunity.softwareag.com/ecosystem/documentation/natural/nat422mf/parms/td.htm). If your users invoke Natural via a terminal emulator, a macro might select the time zone from their operating system and provide it as a dynamic parameter.

I would suggest a change/enhancement request. I can see at least two areas:

  • ability to associate the TD parameter with a Natural Security profile. This would allow you to assign a TD value to a user or group. An API (USR* routine) to allow dynamic modification of TD at run time would be handy for cases where the user security group was not suitable for assigning time zone.
  • a collection of system variables/functions to allow the time to be stored in a time-zone independent manner (similar to *TIMX, but based on UTC perhaps), but when displayed would be local time (according to TD offset) or, with a parameter, to whatever timezone was preferred (eg *UTCX(-5) or *UTCX(‘USA-EST’))