Seems unnecessary and parochial ;) Shouldn't the host/server send the date/time to the display (client/server, I don't really care) and let it decide how to display the time? After all, if I'm at a desktop in Uruguay, why should I have to care whether the host/server is in Manhattan or Zimbabwe? Hmm, what display attribute could be used to indicate a temporal field?
On Mon, 8 Nov 2010 13:38:05 -0600, Paul Gilmartin <[email protected]> wrote: ... > >The paradigm of an offset from UTC to civil time which must be >changed semiannually is adverse. It's better to have a function >which takes a UTC value, past, present, or future, as its argument >and returns the corresponding civil time. Such a function needs >to be updated only when legislation alters the boundaries. > >And the concept of exactly two time zones, "GMT" and "LOCAL" is >parochial. There are 24 zones (actually far more), and a proper >conversion function has two arguments: > > localtime( UTC, zone ) > >... dealing with the need to operate various LPARs with >different local time zones but the same STP. In fact, it >even allows z/OS processes within the same LPAR to operate >with different time zones as easily as: > >u...@mvs:130$ TZ=GMT0 date >Mon Nov 8 19:29:06 GMT 2010 > >u...@mvs:131$ TZ=MST7MDT date >Mon Nov 8 12:29:09 MST 2010 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
