root@ucbvax.UUCP (09/09/83)
From GEOFF5@SRI-CSL Fri Sep 9 06:17:16 1983 Just wanted to let you know from the horse's mouth that the VMS time format is indeed local time. We thought about implementing time zones, but when you start dealing with things like time stamps on objects (e.g., files) and viewing them from different machines in different time zones (or transporting a disk from one time zone to another), things can get very confusing and hairy. We finally decided that the best solution was to keep it simple and run the system in local time, and have everyone understand what was going on. Or, you can run your system(s) on GMT and really understand what's going on. By the way, the 64 bit clock isn't really hardware. It's just a quadword in the exec that gets updated by the clock interrupt service routine, which drives off the machine's interval timer. While the format has 100ns resolution, it only gets updated at 100hz. --------
daemon@ucbvax.UUCP (09/21/83)
From GEOFF5@SRI-CSL Wed Sep 14 23:36:04 1983 Your justification for using local time instead of GMT would seem to justify precisely the opposite. If I've got a distributed system that spans a time zone boundary, I want all nodes to have a common mapping from time to "time representation"; I don't want to have to look at every message that crosses the boundary and modify the time rep. Local time and GMT are, in one sense, equally valid views of the same thing. Neither is "time"; both are "views of time". When there is no "correct" reference point, one picks an arbitrary one (which, by world-wide agreement, is GMT/UTC). Most computer uses of "time" are satisfied by an arbitrary, but absolute and universal scale, or by elapsed time. When local time is need, one can use a conversion function to map from a "time" value and a time zone (and a "DST is observed" bit) to provide local time. You'd use this only at the highest (user-friendly) levels, say to print a directory listing or to know when to turn on the porch light. There's no need to store representations of local time in internal format, except for the infrequent case when a command such as "turn on the porch light at 7pm" is compiled; even there, late binding is really the right way to go. There's every need to store a representation of universal time, unless your computer system isn't ever going to be used on a network. The problem of getting loosely connected computers to agree on what time it is is another one entirely; there has been some careful theoretical work done on it in the past few years. -------