It is *possible* to use locales to offset the time. None of the system locales (to my knowledge, anyway) contain a time-zone offset, but it's possible to create locales that do this by following the procedure outlined in the following article:

To retrieve the time with the given offset, you must call the _C_PSX_localtime API (the *POSIX version of the localtime() function)
So this is an extremely obscure technique, because the normally-used locales don't use this function, and the typical methods of retrieving the current time don't use it, anyway! But, the support does exist, it's just obscure.


Does using a locale really make sense for this?! Think about it for a moment... Our normal locale in the USA is en_US (which stands for "english, United States") -- does it make really make sense for _that_ to imply a particular time zone?

A locale is intended to specify a set of cultural/linguistic values, such as how a date is formatted (M-D-Y vs D-M-Y, for example), which symbol (comma vs period) indicates decimal points, etc. But does a particular locale really represent a particular time zone?! I guess it would in a small country, where the entire country fits in a single time-zone. But, consider a country like the USA... Obviously, we have pacific, mountain, central, and eastern time zones. But, then there are also locations that don't observe daylight savings.. then, there are Alaska and Hawaii that are not in our four main time zones, then there are the various islands and other territories we own.... instead of just "en_US", we'd need more than a dozen locales. Does time zone in a locale really make sense? Seems to me, it'd make more sense to have a time zone job attribute (specified via a jobd)

But, anyway... what you're asking for doesn't exist in RPG right now. You can either code your applications to call a routine (of your own devising) that returns the time (where you can make adjustments as needed.)

IMHO, a proper architecture for an application would save all date/time values in UTC. Applications would only adjust them for the user's time zone when displayed to a user (on-screen, printout, etc.) If you wrote your own routines, this wouldn't be hard to implement, but using the IBM tools or event vendor tools like ANYDATE, this would be quite difficult, since you always need to distinguish whether you're getting the time in UTC to be stored in a database, vs getting the time in the user's local time zone. (There are IBM APIs that do this nicely, but wrapping them with your own routines would make them much easier to call.) This paradigm would make it possible to have users scattered throughout the world, but always display the date/times in the user's time zone. (Note that this is the norm in the Unix applications I've used, and many Windows apps as well.)

For just testing (which seems to be your scenario), you can use a vendor product like ANYDATE from Help/Systems that lets you change the time on-the-fly.

(or do your own low-level MI programming to write your own tool like ANYDATE -- not for the faint-of-heart!)

On 4/16/2012 10:11 AM, DeLong, Eric wrote:

I don't want to beat this to death, but locale settings are about
"formatting output" given a locale. I don't think it is common at
all to apply UTC offset (or timezone / DST) using locale. Even if
locale did support this, what is the effect of this on your database
and applications? The data stored in the file is whatever you put
in. Is the timestamp stored by DB2 as UTC (0 offset), so that after
you read a record, you can manually apply job level offsets to
present the timestamp in locale context?

All of that can be done if you write your applications that way...
The developer must apply those conversions to date-time values so
that it overrides the standard default behavior of the platform.

In this case, OS400 does NOT manage date-time offsets in the database
I/O functions, so all date/time functions take on the same context...
System time...


This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].