[Openroad-users] eClient & Timezones - CORRECTION KB415539not KB415439

Thu Apr 10 22:18:47 EST 2008

Hi Darren,

I haven't experimented with timezones in the eCient but I have a few questions which are relevant to running the same eclient application in different timezones:

1.  Are all of the timezone binary files contained within the eClient files or is only the timezone file relevant at the time of compilation of the eClient file included?
2. If all of the timezone binary files are included in the eClient then it would be possible for the eClient at startup to interrogate the OS Registry to find the timezone of the PC and then using the 'CurSession.TimeZone = 'AUSTRALIA-WEST'; to set the appropriate timezone. 
3.  'CurSession.TimeZone' can be set within the running application before a connection to a database is made. I presume that if the eClient is not using Ingres Net then there will be no database connection anyway.

The other aspect of your statements below is the question about the exact use of the 'DATE' field that you are referring to.

1.  If you need to see the LOCAL time for timezone A at which something was/is to be done and you are viewing it in a different timezone then there are 2 ways  to do this:
    a. The first way is to store the LOCAL time as a character string so that whenever it is examined from anywhere in the world it will always display as the LOCAL time at the source not the viewing point.
    b. The second way would be to store the time as GMT in a Date or character field and then convert it to a character string for the appropriate timezone. This method applies to working with just single date/time values.  It will not work very well when using sets of data

2. If you need the stored date/time to be able to sequence events happening in different timezones then you will have to store the time as GMT. Only then can you get a valid sequenceing when referencing different timezones.

If you try to use one field/column to fulfill the requirements of 1 and 2 above you will run into all sorts of problems and you would probably end up using a second field to store the actual timezone for the date entry anyway.  My suggestion if you are thinking of using a date-time field for both sequencing as well as displaying local time for different timezones then don't. Just use 2 fields.

Hope this helps,
Bill Allan
Brisbane
  ----- Original Message ----- 
  From: Darren Mason 
  To: 'International OpenROAD Users' 
  Sent: Thursday, April 10, 2008 7:39 PM
  Subject: Re: [Openroad-users] eClient & Timezones - CORRECTION KB415539not KB415439

  (on behalf of Darren Harvey) 

  Thanks for the advice Durwin,

  That gives as some ideas on how to ensure we set the correct timezone at each of our interstate sites. Our immediate thought is to check for an .ini file on the client PC that will contain the local timezone value,  and if it does not exists then prompt the user to select a timezone.  Once this has been done the first time we should be ok from then on. We will start putting ths in place.  The problem we are trying to resolve leads down the path of viewing the data after it has been saved.  The following is based on the Australian timezones.

  Let's use Perth in WA where the is at 9:00am , Sydney in NSW where the time is 11:00am, and GMT being 1:00 at the same time.

  What we will be doing is enabling our Perth users to view the time as 9:00am and save it accordingly - all is good.

  Our Sydney users will view their times as 11:00am, and saving it accordingly so all is good.

  Our understanding is that the times are saved in the db as GMT times, so 9:00am in Perth and 11:00am in Sydney will both be saved as 1:00am GMT.   Now we start introducing an issue.

  If a Sydney user then access the Perth times, the 9:00am will then be displayed as 11:00am because it is applying the Sydney - NSW timezone.  The reverse is true if a user in Perth needed to view times from a Sydney employee.    11:00 am will be displayed as 9:00am.

  We fear needing to introduce text fields to store the times that need to be displayed on each screen, and I expect reporting will become an issue as it will be reporting on a collective set of date fields without knowing the source?

  Any advice on how to address this would be greatly appreciated.

  Regards

  Darren Mason

  MyWorkplace Solutions Pty Limited

  Level 5, 11 Queens Road

  Melbourne Victoria 3004

  Ph.   1300 733 731

  Mob. 0419 337 170

  Fax.  03 9710 1112

  Making Service our Priority

  www.MyWorkplace.com.au

  If you receive this email by mistake, please notify us and do not make any use of the email. We do not waive any privilege, confidentiality or copyright associated with it.

  From: openroad-users-bounces at peerlessit.com [mailto:openroad-users-bounces at peerlessit.com] On Behalf Of Durwin Wright
  Sent: Thursday, 10 April 2008 5:59 PM
  To: International OpenROAD Users
  Subject: Re: [Openroad-users] eClient & Timezones - CORRECTION KB415539 not KB415439

  Are you using the eClient ENVIRONMENT= directive in your eclient in the INSTALL4GL.TXT file that you use to package the eClient application?  An excerpt fron the readme.txt for the eCleint is as follows,

      ENVIRONMENT

          This line can appear ZERO or more times.  The string to the right of

          the first "=" sign is treated as an environment variable specification.

          These environment variables will be set in the eClient runtime process

          before the OpenROAD runtime is initialized.

          The variable name is separated from the variable value by the second

          "=" sign, similar to the syntax for using "set" in a command window.

          Variable values can refer to other variables using the standard %xxx%

          syntax (such as in the %II_ECLIENT_APPDIR% example shown above).

          The following "built-in" variables can be referenced by your own

          definitions:

              II_ECLIENT_APPDIR

                  This will be set to the current eClient application's

                  installation directory, which is also the current directory

                  when the OpenROAD runtime executes this eClient application.

              II_ECLIENT_ROOT

                  This will be set to the parent directory of the application's

                  installation directory.

              II_ECLIENT_LIBDIR

                  This will be set to the eClient shared library installation

                  directory.

              (Other predefined variables are described in a later section.)

          Variable definitions are processed in two passes.  First the variables

          that do not reference any other variables (i.e., those that do not

          contain any "%" characters) are set.  In the second pass, the variables

          that contain "%" references are expanded using the current environment

          settings, and then set.

          The order in which variables are processed within each pass is not

          defined.  Therefore, you should not attempt to use more than one level

          of nesting in your variable definitions.

  Normally the II_TIMEZONE_NAME is retrieved from the SYMBOL.TBL for the nstallation.  The eClient does not use a SYMBOL.TBL.  If there is an Ingres installation on the machine where the eClient is deployed, then you could use the ENVIRONMENT directive to set II_SYSTEM to an explicit value.  

  An alternative to the SYMBOL.TBL is to explicitly use the SET command to specific an II_TIMEZONE_NAME vlaue.  This environment variable cannot be set after the eClient starts the underlying OpenROAD runtime.  The ENVIRONMENT directive is processed prior to the eClient OpenROAD runtime initializing and performs a SET on behalf of the eClient prior to the initialization of the eClient OpenROAD runtime.

  Take a look at Ingres KB415539, "How to run an eClient application using different settings for II_W4GLAPPS_DIR to use different image versions".  It specifically refers to II_W4GLAPPS_DIR but the technique cold easily be generalized to having a previously Windows environment variable set that contains the local value of II_TIMEZONE_NAME.

  Durwin Wright | Sr. Architect | Durwin.Wright at ingres.com | Ingres | 500 Arguello Street | Suite 200 | Redwood City | CA | 94063 | USA  +1 650-587-5523 | fax: +1 650-587-5550 

------------------------------------------------------------------------------

  From: openroad-users-bounces at peerlessit.com [mailto:openroad-users-bounces at peerlessit.com] On Behalf Of Darren Harvey
  Sent: Wednesday, April 09, 2008 7:17 PM
  To: 'International OpenROAD Users'
  Subject: [Openroad-users] eClient & Timezones

  I have a question re the handling of Timezones within an eClient environment.  

  Assume the time in NSW is 11:00 and Western Australia is 09:00.

  We have built the Cab file through the OR Web-Publisher and specified an environment parameter of 'II_TIMEZONE_NAME=AUSTRALIA-NSW'.  This works fine in NSW, however when users in Western Australia run the eClient, they see the 'current' time as 11:00 instead of the correct local time of 09:00.  (I assume this is correct from an OR point of view? But unfortunately it isn't what we require.)

  Does this mean we need to build a separate Web application for Western Australian users, that specifies a parameter of 'II_TIMEZONE_NAME=AUSTRALIA-WEST'? And that this would then show the 'current' time as 09:00.

  I hope this makes sense.

  Thanks

  Darren

  Regards

  Darren Harvey

  MyWorkplace Solutions Pty Limited

  Level 5, 11 Queens Road

  Melbourne Victoria 3004

  Ph.       1300 733 731

  Mob.     0400 398 188

  Fax.      03 9710 1112

  Making Service our Priority

  www.MyWorkplace.com.au

  If you receive this email by mistake, please notify us and do not make any use of the email. We do not waive any privilege, confidentiality or copyright associated with it.

------------------------------------------------------------------------------

  ________________________________________________________________
  OpenROAD-Users mailing list

  You can maintain your subscription here:
  http://www.peerlessit.com/mailman/listinfo/openroad-users

  To unsubscribe click on this link
  mailto:openroad-users-unsubscribe at peerlessit.com&subject=unsubscribe

  To subscribe click on this link
  mailto:openroad-users-subscribe at peerlessit.com&subject=subscribe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.peerlessit.com/pipermail/openroad-users/attachments/20080410/8d92cdd2/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1436 bytes
Desc: not available
Url : http://www.peerlessit.com/pipermail/openroad-users/attachments/20080410/8d92cdd2/attachment.jpe 