• Introducing Dark Mode! Switch by clicking on the lightbulb icon next to Search or by clicking on Default style at the bottom left of the page!

Time Zones

We are due shortly to bring our UK office onto OneWorld. We will connect
them via Citrix servers to our New Zealand database and application server.
One of the issues we have is that NZ is at least 12 hours ahead of the UK
and hence some dates and times for their transactions will be incorrect if
the dates and times are defaulted from NZ date and time.

I think we can get around a lot of the transactions by giving them their own
Citrix server set to UK time, but I don't really want to have to set up a
separate application server for them to get around this.

I was wondering what solutions other companies with branches in different
time zones are doing. Any suggestions would be appreciated.

Regards

Marty Fleming
Business Analyst
Richmond Limited

Phone: +64 +6 8786464 Ext 8168
Fax : +64 +6 8780959
Email: mailto:Marty.Fleming@Richmond.co.nz
Web Page: http://www.Richmond.co.nz/

Site Specifications
OneWorld: Xe
Database: Oracle 8i
Enterprise Server: Intel NT
Clients O/S: NT
 

Kmxjde

Member
Marty,

I may be wrong, but I don't think setting up another citrix server will resolve your issue. Instead I think you will need to setup another application server for your UK users to process their ube's. The reason I say this is because the time/date stamp on your transactions are coming from the server that processed the UBE.

Rumor has it that with the new B9 release, a new universal time/date scheme will be used.

KmX
 
Kmx

Thanks for your reply on this.

Yes I agree with you that any ube's running on a shared apps sever will get
the date and time stamp from NZ, but if we have their own Citrix server for
transaction processing set for UK time with bsfns etc mapped to the Citrix
server rather than the logic server I think that they should get UK date an
time on transactions. (I know, I know - you are supposed to map bsfns to the
logic server in a Citrix environment, but what you are supposed to do and
what you actually can do are two different things and I know I can get away
with this configuration.) As you rightly point out, this still leaves me
with a problem of a shared apps server!


I did have a reply outside the mail list which suggested this could be done
on a Unix server. The substance of the reply was as follows:

"I have solved this same problem in a very easy way on a Unix box.
On Unix we startup the queues from shell scripts. I simply set the TZ
(timezone) environment variable to a desired value before starting the
different queue deamons (=service). Any UBE send to a specific queue will
have its own idea of its timezone. It actually worked!"

We are an NT site (W2000 on the servers actually.) Does anybody know if
there is anything similar on NT?

Still hunting for that elusive solution!

Regards

Marty Fleming
Business Analyst
Richmond Limited

Phone: +64 +6 8786464 Ext 8168
Fax : +64 +6 8780959
Email: mailto:Marty.Fleming@Richmond.co.nz
 

Tom_Davidson

VIP Member
Marty,

Welcome to the joys of international business.

Some things you may want to consider before trying to implement multiple
time zones in OW.

1. OW internal DTS (Date Time Stamps) for system processes will always be
from the server the business function runs on. This can cause problems
trying to purge/sync/debug as you need to know the MACHINE the record was
created on to know where the DTS came from. This is especially problematic
for shared system files.

2. As you bring up other offices around the world problem 1 becomes
completely unmanagable.

We 'solved' the problem by stating that our 'Business time' is GMT. By
doing this we gained t he following:

1. We have EVERYBODY mad at us, as no one is in the GMT time zone.
2. We can't be accused of being North American centric (where our home
offices are), as they are mad also.
3. Our purges, Data Warehousing syncronization, and debugging needs can
be met with 'standard' methodologys.
4. GMT is a recognized world wide standard. It is easily defensible.
5. GMT does not change +/- one hour twice a year, we do not have to try
to figure out how to sync times when Europe changes one weekend, NA
another, Asia/Pacific a different time. Not to mention different
states/provinces/counties/cities which choose not to change times.
6. For legal documents which need local DTS printed on them, EDI trans,
and other customer facing data, we have a conversion table to account for
where the document is going to.

HTH.

Tom Davidson
B7332 SP 11.3, AS/400 V4R5, SQL 7.0 CO, TSE's






I was wondering what solutions other companies with branches in different
time zones are doing. Any suggestions would be appreciated.








OW 7332 SP 11.3VER, NT 4.0 SP 5, TSE 4.0 SP 4, Metrframe 1.8, CO SQL 7.0
 

JonFoster

Member
Was curious what you ended up doing to solve your time zone problem? We will be dealing with the same thing shortly with US and Australia?

Thanks in advance.
 
Top