User Time Zone Settings

Timezone is usually a user preference.  In many cases, when a user connects to Citrix, they send along their preference of timezone and the Citrix session then reflects the same timezone as the user's desktop.  

There aren't any easy ways to pass along the timezone preference across TELNET so we have a preference configuration table (by user) where the users store their current timezone preference in the OE database itself. Maybe SSH has a way to pass the timezone (at the OS level) via an environment variable,  I haven't tried that.

The way an ABL session (character or otherwise) can pick up on a preference of timezone is by assigning an offset in minutes (via SESSION:TIMEZONE).  If that is not set manually (?), then the ABL session gathers a timezone offset from the host OS.

Hope this helps to get you started. David

BTW, we've had quite a bit of pain getting OpenEdge ABL to support arbitrary client timezones.  You should search the KB thoroughly every time you see something unexpected - because there are quite a number of well-known issues.  Many are documented but there are other serious issues that are not (eg. community.progress.com/.../76433)  

I appreciate the feedback.  This is a new opportunity where we are helping migrate another vendor's application and infrastructure.  It may get pushed back to the coders if I can't find a simple way to implement timezone redirection at the domain login level.

Once I test things out, I'll post an update.

Bob

Why not use different logins for different timezones?

Bob, I would recommend that you plan on having the coders work on this either way.  The problem is that ABL programs often use TODAY and TIME.  It sounds like your intention is that these would be impacted by the timezone (a user preference).

But ABL programs frequently use TODAY and TIME in the cases where they need absolute/chronological timestamps as well.  It is unlikely that the ABL programmers made a distinction between the places where TODAY/TIME were representative of an arbitrary timezone (based on the user preference) and the places where they needed to represent absolute/chronological time.  Long story short - you might end up with timestamp data in your database that is an unwieldy mixture of arbitrary and totally unqualified timezones.  Progress OE didn't even have the DATETIME-TZ (or even DATETIME) data type in the database until relatively recently; so even well-meaning programmers were pushed into very bad programming practices where timezones are concerned.

> On Jan 12, 2016, at 8:46 AM, dbeavon wrote:

>

> Progress OE didn't even have the DATETIME-TZ (or even DATETIME) data type in the database until relatively recently

it has only been 12 years.

as previously mentioned, you can use the SESSION:TIMEZONE attribute to specify in what timezone you want the session to operate. if not set, then system supplies timezone

then you can set the SESSION:DISPLAY-TIMEZONE to specify what timezone should be used when formatting output. when SESSION:DISPLAY-TIMEZONE has not been set, then SESSION:TIMEZONE value is used.

the TIMEZONE() function gives the the timezone offset of a datetime-tz value

TIMEZONE() with no arguments returns the timezone offset the session is using.

"Relatively" recently is the key.  I'd take a bet that the character client app he is talking about predates those data types.  We still have tons of so-called "time" data stored in the character format in our databases ("HH:MM:SS").   I suspect it is not uncommon.

The point I was making was about whether or not it is reasonable to expect the app would work "as-is" with multiple arbitrary user timezones being supplied from the system to the ABL session, (instead of a single timezone).

You pointed to a lot of stuff a programmer can use to write robust timezone-aware apps.  But Bob is talking about sending the user's preference of timezone into an ABL app without any programmer's involvement.

This is a good thread.  I like the banter because it has exposed a number of options and potential pitfalls.  Thanks for the feedback.

In the perfect world, I could get my domain connection to grab the TZ of the device in question and simply pass that into my telnet session.  For RDP or Citrix clients this is called Time Zone Redirection.

As David points out, I am initially researching ways to deliver this without touching the code.  It is not my code to touch but I have a friendly relationship with the developers so we can go down that path as needed.  My assumption is that I will be far more efficient delivering this if we do not need to code, test and certify a heap of new enhancements.

I also appreciate David's comments about legacy code.  There is a lot of that about and I agree that a good chunk of it carries on in less than today's 'best practices'.  In my case however, all of the code is new since the Date-Time enhancements came out.  It will take some review though to make sure none of the old ways sneaked into the new code.  While the code is new, the developers may not have embraced the newest techniques.

We are setting up a test to see if a telnet connection to either a Terminal Server or Citrix box can redirect the TZ.  I'll post the results once we know more.

> On Jan 12, 2016, at 12:37 PM, bbrennan wrote:

>

> My assumption is that I will be far more efficient delivering this if we do not need to code, test and certify a heap of new enhancements.

indeed.

however: you /might/ not need to do more to the code than set the session timezone and display timezone at the top.

but if all the different timezones are using the same database, then you are in big trouble.