|
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.
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.