Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!genrad!decvax!ucbvax!VENUS.YCC.YALE.EDU!leichter From: leichter@VENUS.YCC.YALE.EDU.UUCP Newsgroups: comp.os.vms Subject: Re: Changing from daylight time to standard time Message-ID: <8711020746.AA21981@ucbvax.Berkeley.EDU> Date: Thu, 29-Oct-87 12:11:00 EST Article-I.D.: ucbvax.8711020746.AA21981 Posted: Thu Oct 29 12:11:00 1987 Date-Received: Tue, 3-Nov-87 04:09:23 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "Jerry Leichter" Organization: The ARPA Internet Lines: 80 Since everyone works out their favorite way to kludge DST why don't we all submit SPRs and get DEC to fix it once and for all. Simply have DEC maintain in kernel all times in a fixed timezone (GMT?) and have each site specify their timezone and if they are on DST. This way a file created on VAX A in London will appear to have the same creation date on VAX B in Los Angeles if it is transfered. As it is now with networks growing you can get files that have dates in the future. It appears that it can be implemented fairly easily so why not push for it in VMS 5.0 so we can all sleep at 2am each spring and fall. Have you though about what this would do in practice? If I create a file on my machine in New Haven, then move it to your machine in California, what does "the same time" mean? a) When we look at the timestamps, we see the same numbers. b) When we look at the timestamps, we see different numbers reflecting the same "time point" in our two areas. (a) is what happens today. It has a major advantage in that I can call you on the phone and check if you have "the latest version" - i.e., the one with a timestamp that is the same as mine. In general, it means that visible timestamps are invarient: They always look the same. (b) is what you would get if you stored all times in GMT - well, UCT if you want to get technical about it - and converted them to the local timezone every time you needed to display them. It means that (visible) timestamps on files change - you can't compare them across systems. Actually, it's worse than that: Suppose I create a file at about 5:00 the evening before the time change. The next morning, I try to find it. Guess what: The time displayed for the file is now not "about 5:00", but "about 4:00" (or "about 6:00"). While (a) has its drawbacks - such as "time travel" - (b) isn't a great blessing either - it can get very confusing. Imagine moving your mail file to a system in Japan and finding that all your old mail apparently arrived in the wee hours of the morning! A truely general solution would have to deal with a lot of related issues. For example, if I'm logged in to a machine in a different timezone, should I see times local to my terminal, or times local to the system? Imagine being logged in to a workstation, with a window SET HOST to a system in a different timezone. The only system I know of that seriously considered these issues was Multics. I don't know the details, but as a start each terminal had a "preferred time- zone" that would be used in producing time displays for it. But if you want a really complete job - and I don't know if Multics went this far - every time value in the system must carry with it an indication of the time zone in which it was created (but is it the system's time zone or the terminal the creator is logged into?) Then you can get meaningful displays that show that the file I just moved from New Haven to California was created at 8:23EST - or at 5:23 local time, if I prefer. Or at 6:23 if I'm dialed in from Salt Lake. (Oh, but don't forget that there is NO accepted standard for timezone abbrevi- ations - BST IS either Bering Strait Time or British Summer Time.) Simply changing to method (b) is something you can do today: Just set your system time to UCT and leave it there. Sure, the times on LOCAL files will look strange - but just think, all the files you transfer from London will be set up just right - except, of course, when England is on Summer Time! (Reminds me of the friend who's explanation of his odd schedule - he slept from about 4:00AM to noon - was, "Hey, millions of people are on the same exact schedule. It just happens that most of them are in England.") As for "SHOW TIME" being wrong - well, digital watches are pretty cheap! :-) A REAL fix would be a rather complex matter, and not something that "can be implemented fairly easily" for V5. Oh, and BTW, you'd STILL have to do something every Spring and Fall to change over from DST to ST. And don't suggest doing it automatically! There is no algorithm, fixed over time, that will tell you when to make the change - Congress keeps changing its mind, there have been local differences in the past - and that doesn't even MENTION the rest of the world, which follows its own (many) rules. Unix made the mistake of hard-coding an algorithm in at one point. Congress changed its mind. We had a number of systems running "in the next timezone over" for a while to compensate. -- Jerry ------