|
midrange.com
Pure speculation on my part, but in V5R3 there is a read-only TIMZON job
attribute which is always set to the value of the system value QTIMZON.
Being a job attribute one could, looking at how many other job attributes
are determined, envision it being set at some point based on *JOBDs,
*USRPRFs, SBM* interfaces, and the like. The *TIMZON object of course is
where you find information such as DST observance, offset from UTC, time
zone names, etc.
Bruce Vining (speaking only for myself)
"Booth Martin"
<booth@xxxxxxxxxx
om> To
Sent by: "Midrange Systems Technical
midrange-l-bounce Discussion"
s@xxxxxxxxxxxx <midrange-l@xxxxxxxxxxxx>
cc
10/11/2005 09:31 Subject
AM RE: Time Zones
Please respond to
Midrange Systems
Technical
Discussion
The idea sounds great, but how does one implement it on an iSeries where it
is highly likely that users will be in at least 3 time zones? Do you
connect the offset to the user ID, the workstation? to each individual
sign-on session? Or maybe you use GMT as a standard and teach the users
about offsets? The whole conversation must be a constant lunchtime
conversation in the IBM labs. UNIX does it, but is the UNIX solution
useful
for an iSeries instalation?
---------------------------------
Booth Martin
http://www.martinvt.com
---------------------------------
-------Original Message-------
From: Midrange Systems Technical Discussion
Date: 10/11/05 09:13:15
To: Midrange Systems Technical Discussion
Subject: RE: Time Zones
I would certainly hope that the timestamps would be normalized to a
standard such as UTC which does not have to worry about CST/DST and
offsets. A program opening a file containing these types of timestamps
could then work with the time values as mapped to the current job time zone
(where CST/DST and offsets would apply).
Conceptually I would see this as similiar to CCSID processing on i5/OS. In
V5R3 you can have a character field in a database tagged as UTF8 (CCSID
1208). If a job running CCSID 37 opens the file and reads a record i5/OS
automatically maps the data from 1208 to 37. Likewise if the program
writes/updates the database field i5/OS will accept the CCSID 37 data from
the jobs buffers, map to 1208, and store the data. Another job, running in
CCSID 500 would do the same except replacing 37 with 500.
So in theory we could have a database field identified as being UTC
normalized. A job running time zone QN0600CST (Central Standard Time)
opens the file and reads a record. The field timestamp value is
automatically mapped by i5/OS to the appropriate value in QN0600CST
(applying DST rules as they are defined for that *TIMZON). The program
writes/updates the field and i5/OS takes the QN0600CST data, maps it to
UTC, and stores the data. Another job, running in time zone QP0900JST
(Japan Standard Time), reads the same record and processes the same
timestamp but the values here are based on QP0900JST rather than QN0600CST.
This actually would be superior to the previous CCSID example as you don't
have to worry about the data loss inherent in mapping say Greek data stored
in UTF8 to an English job CCSID.
Bruce Vining (speaking/typing only for myself on what would be nice)
"Goodbar, Loyd
(ETS - Water
Valley)" To
<LGoodbar@borgwar Midrange Systems Technical
ner.com> Discussion
Sent by: <midrange-l@xxxxxxxxxxxx>
midrange-l-bounce cc
s@xxxxxxxxxxxx
Subject
RE: Time Zones
10/11/2005 08:41
AM
Please respond to
Midrange Systems
Technical
Discussion
The only issue with this is if the system timezone changes after timestamps
are stored (CST/DST comes to mind). Ideally the UTC offset as of that
timestamp would be part of the date data. See the email timestamp format:
Mon, 10 Oct 2005 12:49:07 -0400. A variation could extend the ISO format:
2005-10-10.12.49.07.000000.-0400.
Loyd Goodbar
Senior programmer/analyst
BorgWarner
E/TS Water Valley
662-473-5713
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Joe Pluta
Seems to me there should be an agreed-upon "standard" for database
times, Rob, and GMT is as good as any. How the system shows that time
should be a switch on the job, no different than showing the date in
MM/DD/YY or DD-MM-YY.
> From: rob@xxxxxxxxx
>
> Which brings up an interesting point...
> If I record a timestamp in a file will it store it in UTC? If someone
> else queries that file (if/when i5/os supports this) will they see the
> timestamp in their timezone?
--
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.
--
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.
.
--
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com 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].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
