new@udel.edu (Darren New) (11/10/89)
I think it would be useful in the future to have a field in preferences describing your timezone. It should be settable from -12 to +12 or "undefined" (the default). This would allow programs that need UTC to get to it without fouling up older programs or programs that don't care. Time on the system would remain as local time. -- Darren
sean2@stretch.MUN.EDU (Sean Hogan) (11/10/89)
In article <3753@nigel.udel.EDU> new@udel.edu (Darren New) writes: >I think it would be useful in the future to have a field in >preferences describing your timezone. It should be >settable from -12 to +12 or "undefined" (the default). >This would allow programs that need UTC to >get to it without fouling up older programs or programs >that don't care. Time on the system would remain as local >time. -- Darren Please oh please, if anybody considers doing this, remember that some places in the world (yes, even in North America) do not operate on one-hour divisions of zone! The island part of Newfoundland runs on Newfoundland Standard Time, one *and one half* hours later than Eastern Standard Time. I believe (not having an atlas handy) that other [some even more obscure :-)] places in the world are in the same situation. Sean ---------------------------------------------------------------------------- Sean Hogan, graduate student sean2@{garfield,stretch}.mun.{edu,ca} Department of Computer Science, Me@bambam.mun.edu (Amiga) Memorial University of Newfoundland ...!uunet!garfield!sean2
mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (11/10/89)
In article <455@stretch.MUN.EDU> sean2@stretch.UUCP (Sean Hogan) writes: <In article <3753@nigel.udel.EDU> new@udel.edu (Darren New) writes: <>I think it would be useful in the future to have a field in <>preferences describing your timezone. It should be <>settable from -12 to +12 or "undefined" (the default). <>This would allow programs that need UTC to <>get to it without fouling up older programs or programs <>that don't care. Time on the system would remain as local <>time. -- Darren < <Please oh please, if anybody considers doing this, remember that some <places in the world (yes, even in North America) do not operate on <one-hour divisions of zone! I vaguelly recall there are some 1/4 hour divisions floating around, also. Could be wrong, though. Of course, just allowing the user to specify an offset from UTC isn't really an improvment over the current situation. All that does is allow you to ask for (unspecified) local time, or UTC. That doesn't seem very usefull to me. After all, what you _really_ want is that offset, plus the _name_ of the timezone. Most people (in the US, anyway) probably want to know whether they're on DST or not. Since the latter is _very_ irregular, and variable by law, you really need some kind of table the user can modify. Fortunately, this problem has been dealt with elsewhere. It was done to deal with the last time the US Congress decided to change the DST rules (*), and should be mostly portable. Even if that's not, the solution should be usable, suitabley tweaked for the Amiga environment. 1a) Add to preferences a scrolling list similar to printers. The list is the contents of devs:timezones. or 1b) Add a "settz" command, similar to "setmap". It also uses devs:timezones (doing both might be possible). 2) devs:timezones contains a set of binary files for the major timezones. The binary file contains the TLA used for that TZ, including the one for DST if it's apropriate. It also contains rules for determing when DST goes into affect for any time in the past, as well as the future. The extras disk should contain a program to turn text files into timezone data files, with documentation. 3) libs:date.library containes routines for turning timestamps into printable dates. When opened, it checks preferences (or an env: variable - doesn't really matter) and loads the binary data from the appropriate devs:timezones file. 4) The system utilties are converted to use the libs:date.library. Other things follow as they wish. 5) The user, when they get the machine, sets the timezone, then sets the clock to the correct time for their timezone. The utility for setting the hardware clock sets it to UTC, and everything works from there. The user never has to touch the clock again, barring glitches. That's just one scenario. Seemed like the obvious one to avoid having to read in the binary file every time you needed the date. Others are possible. One key fact of this is that the code for most of this _already exists_. I think it's PD (I'll find out ASAP). The other is that this problem has been fought - and mostly defeated - before. Instead of repeating the mistakes of others, we should learn from them. <mike (*) For those of you who don't follow such things, the US Congresscritters are talking about changing it _again_, and moving the fall dicontinuity back a couple of weeks on presidential election years. -- Lather was thirty years old today, Mike Meyer They took away all of his toys. mwm@berkeley.edu His mother sent newspaper clippings to him, ucbvax!mwm About his old friends who'd stopped being boys. mwm@ucbjade.BITNET
new@udel.edu (Darren New) (11/11/89)
In article <1989Nov10.083157.4844@agate.berkeley.edu> mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes: >In article <455@stretch.MUN.EDU> sean2@stretch.UUCP (Sean Hogan) writes: ><In article <3753@nigel.udel.EDU> new@udel.edu (Darren New) writes: ><>I think it would be useful in the future to have a field in ><>preferences describing your timezone. It should be > >Of course, just allowing the user to specify an offset from UTC isn't >really an improvment over the current situation. All that does is >allow you to ask for (unspecified) local time, or UTC. That doesn't >seem very usefull to me. After all, what you _really_ want is that >offset, plus the _name_ of the timezone. Most people (in the US, >anyway) probably want to know whether they're on DST or not. Since the >latter is _very_ irregular, and variable by law, you really need some >kind of table the user can modify. Actually, I was trying to make it simple and compatible. By specifying the offset from UTC (ok, and the name too) you can allow programs to figure out local time and UTC. The user would have to change the offset from GMT at the start/end of daylite savings just as he/she now must change the clock. My main intent was for (say) file servers or data base handlers. At the server end, the server would do an Examine(), use local preferences to translate the DateStamp to UTC, send the packet. The client would get the packet, convert back from UTC to local time using the client's preferences, and all is well. I don't offhand see the need for anything more complex to be built in. If you need to really know the UTC time for a time in the past, I suppose a library could be built to translate UTC into local time for any time including ones in the past. I still think things should all be stored in local time. >One key fact of this is that the code for most of this >_already exists_. I think it's PD (I'll find out ASAP). It came thru *.sources a while back. I've downloaded it if you want. My point is that all this could be done just by specifying the timezone name in Preferences. Specifying the UTC offset allows programs to do simple time translations of "right now" easily and without other support. Putting the timezone name in Preferences allows 3rd party libraries (or standard libraries) to be written to solve the much more complex problem of translating arbitrary time into UTC and back. I think it would be mostly pointless to use UTC in things like FileInfoBlocks; it would be incompatible and usually not needed. On the occasion it is needed, THEN use the standard library to translate. -- darren