> If I create a file at 15:00 EDT on September 1, 1983, as shown by QUERY TIME > on that day, I expect CMS to show me 15:00, Sept 1, 1983 EDT forever. Ah ha! Yes, CMS will tell you that forever (via LISTFILE or your favorite CMS filesystem command) - same time, every time.
But if I recall correctly (more in doubt every day) CP is less friendly. A 'CP Q sfid ALL' (and other SPOOL file-related) command return times one hour apart depending on whether the command is issued on one side of the timezone boundary or the other. That 1-hour time change can lead to surprising application effects. That's probably not worth any development effort, but it should be understood and noted (perhaps in some future edition "Usage Notes" update). Mike Walter Aon Service Corporation The opinions expressed herein are mine alone, not necessarily those of my employer. -----Original Message----- From: CMSTSO Pipelines Discussion List [mailto:[email protected]] On Behalf Of Alan Altmark Sent: Thursday, April 14, 2016 13:38 To: [email protected] Subject: Re: About DELAY after SET TIMEZONE On Friday, 04/08/2016 at 03:30 GMT, Hobart Spitz <[email protected]> wrote: > An alternative/additional solution, possibly too much trouble, would > be to > add a timezone to the time specification: E.g. 10:30-EST, 18:15-CDT, > etc. Why too much trouble? No all countries change clocks on the > same day. RFC 2822 defines canonical expressions for local time, so there's no real need to invent new ones, but it's important to stress that solving these temporal anomalies requires programmers to acknowledge that - Leap seconds are important - All persistent time values should be stored in TOD clock format I've got people telling me that leap seconds aren't important. And I respond that no, they're not important if you don't care what time it is. [Insert pop music references here.] To me they are as important as the difference between EDT and PDT. If you depend only on the IBM-defined TOD clock epoch, you're off by nearly 30 seconds. How accurate does the local time representation need to be? I say within 1 second of UTC, which is what you will be if you're using STP and you incur a leap second. Could we do better? Yes, but the implementation costs start to rise. If I create a file at 15:00 EDT on September 1, 1983, as shown by QUERY TIME on that day, I expect CMS to show me 15:00, Sept 1, 1983 EDT forever. I don't care what airport I'm in today or how many intergalactic leap wedgies there have been. TOD clock format allows me to maintain precision time values and order, even when I don't need to display microseconds for mere humans. Alan Altmark Senior Managing z/VM and Linux Consultant Lab Services System z Delivery Practice IBM Systems & Technology Group ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 [email protected] IBM Endicott
