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
