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.
> 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? Guess how much I paid for Linux. -- gil
