Eric,
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:
http://www.systeminetwork.com/article/rpg-programming/apis-by-example-locales-apis-and-time-zones-17998
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.
Darryl,
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.
http://www.sequel-software.com/products/anydate
(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...
-Eric
midrange.com
