[archive] Manage time(stamp) when server is CST and remote processing is PST thru EST

[Migrated content. Thread originally posted on 21 January 2008]

Looking for suggestions, methods or approaches how to handle transaction-based processing where there is a central server in one time zone and there are branch operations in several other time zones where time for such things as default time values, rentals, service orders and discount specials need to be based on the zone from which the transaction originated and not the server's time.

This is an existing software package that is written almost exclusively in COBOL.

What is your server platform? I know Linux users can log on to a server from different time zones and have the time returned to them appropriately.

[Migrated content. Thread originally posted on 21 January 2008]

Looking for suggestions, methods or approaches how to handle transaction-based processing where there is a central server in one time zone and there are branch operations in several other time zones where time for such things as default time values, rentals, service orders and discount specials need to be based on the zone from which the transaction originated and not the server's time.

This is an existing software package that is written almost exclusively in COBOL.

What is your server platform? I know Linux users can log on to a server from different time zones and have the time returned to them appropriately.

[Migrated content. Thread originally posted on 21 January 2008]

Looking for suggestions, methods or approaches how to handle transaction-based processing where there is a central server in one time zone and there are branch operations in several other time zones where time for such things as default time values, rentals, service orders and discount specials need to be based on the zone from which the transaction originated and not the server's time.

This is an existing software package that is written almost exclusively in COBOL.

The concern is an accounting package that has a rental module. Currently they have only used this module locally (CST), but they have stores on both US coasts and in-between. So, the task is to alter the occurence of time such that it refelect the applicable zone and not be locked into the server's time (zone).

[Migrated content. Thread originally posted on 21 January 2008]

Looking for suggestions, methods or approaches how to handle transaction-based processing where there is a central server in one time zone and there are branch operations in several other time zones where time for such things as default time values, rentals, service orders and discount specials need to be based on the zone from which the transaction originated and not the server's time.

This is an existing software package that is written almost exclusively in COBOL.

The concern is an accounting package that has a rental module. Currently they have only used this module locally (CST), but they have stores on both US coasts and in-between. So, the task is to alter the occurence of time such that it refelect the applicable zone and not be locked into the server's time (zone).

[Migrated content. Thread originally posted on 21 January 2008]

Looking for suggestions, methods or approaches how to handle transaction-based processing where there is a central server in one time zone and there are branch operations in several other time zones where time for such things as default time values, rentals, service orders and discount specials need to be based on the zone from which the transaction originated and not the server's time.

This is an existing software package that is written almost exclusively in COBOL.

First of all, I would store all times in what military people call zulu time. E.g. a neutral time. Then, with each time storage (for example inside a order record) I would store the location where it was made. In your application then, you will certainly know the timezone for the particular timezone and thus use this as an offset.
For instance. Say that GMT was zulu time. If you had a branch in CET (Europe), the offset would be 1 and a branch in California would have an offset of -8.
Say you created an order in Paris at noon local time. You would then store this as 11 zulu time, but in the branch offset you would set 1.
Then, if this were looked up later, it would have to add the offset to the time stored, giving you 12.
Likewise, for California an order storage at noon would imply a storage in zulu time of 20 and an offset -8.
Now, you probably see that storing the hours are not sufficient as you are exposed to date changes as well. I think I would recommend storing time as julian or perhaps using the INTEGER-OF-DATE and DATE-OF-INTEGER intrinsic functions, add the hours and some code of your own that would handle date changes as a result of hour arithmetic.
On top of this, you will need to handle daylight savings...
As a result of this, I would probably have implemented a module in which I could declare branches and their time offsets to zulu time. Including an entry for daylight savings and when it would occur.
Then, when I store time sensitive data, I would add the following fields.
BRANCH-OF-ORIGIN *Code identifying the branch
ZULU-DATE *Zulu date of order
ZULU-HHMM *Zulu hour minute, resolution is really up to you.
BRANCH-OFFSET * What is the branch offset from Zulu time
BRANCH-DLS * Branch daylight savings offset (it is not always 1 hr, some actually have 1.5 hrs!)

If you are on Windows, there are API functions that give you all of this, including the period of the daylight savings. I am confident such functionality is available on for instance linux as well, but I don't know where you would find this. If Windows is an option, I have an example program that illustrates how to use the Windows API for handling timezones and daylight savings.

So, when you save/load the rental data, you will have to have a module filtering the date information so that it reflects the date time according to the branch where it was created.

You may also choose to not store offset and daylight offset in the record if you do not need a order specific entry but trust that what is in your branch database also applies to historic data. This could of course cause some issues in the unlikely event that some branch all by a sudden should change their daylight savings. For instance, like if Arizona should start using daylight savings.

[Migrated content. Thread originally posted on 21 January 2008]

Looking for suggestions, methods or approaches how to handle transaction-based processing where there is a central server in one time zone and there are branch operations in several other time zones where time for such things as default time values, rentals, service orders and discount specials need to be based on the zone from which the transaction originated and not the server's time.

This is an existing software package that is written almost exclusively in COBOL.

While you can use local machine-specific settings of timezone, etc., this does not actually help if the different servers have their clocks set slightly wrong.

A better approach that we use is to establish the exact time difference at the start of any 'conversation' between two machines.

We do this by calling 'C$PING' which returns the date/time on the remote server running acuserver. We then use the local date/time to calculate an offset in seconds between the two machines.

This offset is then used to create a 'master date/time stamp' for a transaction which is synchronised to the machine running acuserver (the 'master')

Does this make sense?

[Migrated content. Thread originally posted on 21 January 2008]

Looking for suggestions, methods or approaches how to handle transaction-based processing where there is a central server in one time zone and there are branch operations in several other time zones where time for such things as default time values, rentals, service orders and discount specials need to be based on the zone from which the transaction originated and not the server's time.

This is an existing software package that is written almost exclusively in COBOL.

While you can use local machine-specific settings of timezone, etc., this does not actually help if the different servers have their clocks set slightly wrong.

A better approach that we use is to establish the exact time difference at the start of any 'conversation' between two machines.

We do this by calling 'C$PING' which returns the date/time on the remote server running acuserver. We then use the local date/time to calculate an offset in seconds between the two machines.

This offset is then used to create a 'master date/time stamp' for a transaction which is synchronised to the machine running acuserver (the 'master')

Does this make sense?

[Migrated content. Thread originally posted on 21 January 2008]

Looking for suggestions, methods or approaches how to handle transaction-based processing where there is a central server in one time zone and there are branch operations in several other time zones where time for such things as default time values, rentals, service orders and discount specials need to be based on the zone from which the transaction originated and not the server's time.

This is an existing software package that is written almost exclusively in COBOL.

This makes complete sense. Thanks

[Migrated content. Thread originally posted on 21 January 2008]

Looking for suggestions, methods or approaches how to handle transaction-based processing where there is a central server in one time zone and there are branch operations in several other time zones where time for such things as default time values, rentals, service orders and discount specials need to be based on the zone from which the transaction originated and not the server's time.

This is an existing software package that is written almost exclusively in COBOL.

This makes complete sense. Thanks

[Migrated content. Thread originally posted on 21 January 2008]

Looking for suggestions, methods or approaches how to handle transaction-based processing where there is a central server in one time zone and there are branch operations in several other time zones where time for such things as default time values, rentals, service orders and discount specials need to be based on the zone from which the transaction originated and not the server's time.

This is an existing software package that is written almost exclusively in COBOL.

I found the timezone example. Here it is.