Yes, that makes sense.... However, that's already an issue with the current schema anyway... For the long haul, storing all date/time values to GMT seems the best solution.
Eric
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Bruce Vining
Sent: Monday, January 07, 2008 10:10 AM
To: Midrange Systems Technical Discussion
Subject: RE: User Time Zones
Eric,
One problem with storing time values in machine local time (rather than say UTC) is when the data is moved to another system, one that is potentially in a different time zone. The stored time values are now manipulated using the second systems UTC offset values -- which will cause incorrect time values to be used. This problem exists today with database time related fields, journal entries, object description related information maintained with save/restore operations, and the list goes on. Time needs to be stored in an absolute fashion if it is to be meaningful in all environments. Trying to track where the data originated so that a "correct" local time could be derived would be a nightmare :-)
Bruce Vining
"DeLong, Eric" <EDeLong@xxxxxxxxxxxxxxx> wrote:
Bruce,
Maybe a simpler approach might be a job level attribute called QUTCADJ, which applies a job-level offset (+/- n hours) to the system value QUTCOFFSET, so that DB timestamps can still be stored as machine local time. The job UTC adjustment could be re-applied to the stored timestamp to display the time as user-local time values. Any system facilities would simply use machine local time for input and output (as they were designed)...
Just rambling....
Eric
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Bruce Vining
Sent: Monday, January 07, 2008 9:23 AM
To: Midrange Systems Technical Discussion
Subject: RE: User Time Zones
That level of support is certainly possible with i5/OS. You can even see hints of it starting with V5R3 and the read-only job attributes of TIMZON, TIMZONABBR, TIMZONFULL, TIMOFFSET, and DATETIME. To pull this off however would not be a trivial task.
Essentially every function on the system that deals with time values would need to internally normalize time to a standard such as UTC (which strangely enough is what the i5/OS and LIC internal time was converted to in V5R3...) and then map these internal time values to the local job time when externalizing the time value (and reverse the mapping on input). This would imply changes to CL parameters, outfiles, print files, display files (have you noticed that time zone shows up on some i5/OS panels and reports starting with V5R3? ...), APIs, database time related fields -- basically anyplace that time values show up -- so that you could input values using your time zone and another user could retrieve those same values in their local time zone. To complicate matters though the system would not be able (for compatibility reasons -- you don't want some interfaces using job times and other interfaces system times) to externalize any of this job local time support until the
entire system was ready -- suggesting that a staged approach would probably be needed.
Personally I wouldn't be surprised if some key parts of i5/OS and LIC did provide this mapping support in V6R1. Unfortunately you most likely wouldn't be able to "see it" though -- not until all parts of i5/OS and LIC had been able to provide the same level of mapping. So, as was mentioned in an earlier posting, I also wouldn't expect to "see" much change with V6R1.
Bruce Vining
Bruce Vining Services
"Cassidy, Alan" wrote:
I can't see how they could technically handle some implementation like
that. Is there any system that provides functionality like that?
If the locale support can render different times based on the user,
couldn't you just use that "modified" value for your purposes? It's not
THE system timestamp per se, but you could convert that into a timestamp
value for the database.
That should serve the purpose, should it not, unless it's a matter of
skipping the need for a programmed intermediary.
---Alan
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Paul Nelson
Sent: Monday, January 07, 2008 8:19 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: User Time Zones
Thanks, but this only deals with how the time is presented to the user.
The goal is for Suzy in New York to be able to submit a report at 10 AM
EST and have the report time stamped at 10 AM EST. If Bill in
Bakersfield submits the same report at the same time, his report should
be time stamped as 7 AM PST.
According to my well informed sources, this capability does not exist
now, nor will it exist in V6R1.
Paul Nelson
Cell 708-670-6978
Office 512-392-2577
nelsonp@xxxxxxxxxxxxx
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Pat Landrum
Sent: Monday, January 07, 2008 7:12 AM
To: midrange-l@xxxxxxxxxxxx
Subject: RE: User Time Zones
Paul,
Check out the "LOCALE" option in the user profile. This can be set to
different time zones. Check out this link:
http://tinyurl.com/yp2tgq
or
http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/n
ls/rbagsinstalllocales.htm
Regards,
Pat Landrum
Senior Programmer/Analyst
Hanover County School Board
200 Berkley Street - Ashland, VA. 23005
Phone: 804-365-4658 Email: plandrum@xxxxxxx
Notice: This message or any accompanying documents may contain
confidential or privileged information of Hanover County Public Schools.
If you are not the intended recipient, disclosure, copying or
distribution is strictly prohibited by state and federal law. If you
received this message in error, please notify the sender as soon as
possible.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
