On Thursday, 04/14/2016 at 08:04 GMT, Paul Gilmartin <[email protected]> wrote: > On 2016-04-14, at 12:38, Alan Altmark wrote: > > > > ... 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. > > > z/OS tries to do better. The cost seems to be less in implementation > than in confusion to users who find the functions chaotic in their > treatment of leap seconds.
IMO, you either change ALL of the timing functions or you change NONE of them. A "system" should produce self-consistent results. > > > 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. > > > On Linux, I created a couple test files with counterfeit time stamps. Then: > > 505 $ TZ=Zulu ls -lrt --full-time > total 8 > -rw-r--r-- 1 paulgilm paulgilm 29 2010-12-15 12:00:00.000000000 +0000 Dec2010 > -rw-r--r-- 1 paulgilm paulgilm 29 2016-04-15 12:00:00.000000000 +0000 Apr2016 > 506 $ > 506 $ TZ=America/Denver ls -lrt --full-time > total 8 > -rw-r--r-- 1 paulgilm paulgilm 29 2010-12-15 05:00:00.000000000 -0700 Dec2010 > -rw-r--r-- 1 paulgilm paulgilm 29 2016-04-15 06:00:00.000000000 -0600 Apr2016 > 507 $ > 507 $ TZ=Asia/Pyongyang ls -lrt --full-time > total 8 > -rw-r--r-- 1 paulgilm paulgilm 29 2010-12-15 21:00:00.000000000 +0900 Dec2010 > -rw-r--r-- 1 paulgilm paulgilm 29 2016-04-15 20:30:00.000000000 +0830 Apr2016 > 508 $ > 508 $ TZ=Pacific/Apia ls -lrt --full-time > total 8 > -rw-r--r-- 1 paulgilm paulgilm 29 2010-12-15 02:00:00.000000000 -1000 Dec2010 > -rw-r--r-- 1 paulgilm paulgilm 29 2016-04-16 01:00:00.000000000 +1300 Apr2016 > 509 $ > Which of these results would you present differently? I wouldn't change a thing. You asked for the full time and you got it. But you were able to get it because the filesystem uses a Linux "timespec" which is nanoseconds since 00:00:00 January 1, 1970 UTC. But more specifically, you show that Linux knows that sometimes you need the data expressed differently for different reasons. Linux/UNIX TZ handling is significantly better than in CMS, mostly because the effects of a time change are spelled out. Interval timers are unaffected. Absolute timers are affected. > Guess how much I paid for Linux. Doesn't really matter since we're talking about VM and CMS. :-) 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
