On Mon, 10 Mar 2008 19:38:59 -0500, William H. Blair wrote: > >If by the phrase "correct result" you mean "actual LOCAL TIME" >then it can't and won't. That is not what I was trying to show >you. I was demonstrating and illustrating the fact that that, >for input to STCKCONV, you HAVE TO ALREADY HAVE a corrected >local time stamp value (in STCK or STCKE format) in order to >get the correct LOCAL TIME out of the STCKCONV service. The >purpose of the program was to demonstrate that you can't get >what you call the "correct result" out of STCKCONV with JUST >a TOD clock value. > The arguments for storing time stamps in a universal convention, such as UTC are well known; I hope you're aware of them. One of the strong ones is the ambiguity in local time during the autumn Daylight Saving adjustment.
>If you have TOD clock values recorded in a data set (such as >a log file of some sort) then you will simply have to know (if >you did not also record the contemporaneous values of the LSO >and LDTO fields) and be able to reproduce them. In some cases, >of course, this information is known. For example, the value >of CVTLSO is pretty constant, and can actually be looked up in >a table whose argument is GMT, because when LSO changes and, in >the past, has changed, is set by international agreement and is >published. So that does not need to be recorded with the STCK[E] >values, if you are willing to go to the trouble of looking it >up in a table. The value of LDTO is simply time zone-dependent, >and if you know the time zone of the machine that produced the >data then that can be looked up in another table. There are two >boundary conditions that are difficult to deal with, but for the >most part, unless you are writing an operating system or a >product, you don't really need this data recorded. It's easier >of course if you do have it, but it costs you an extra 16 or 32 >bytes in your log records or whatever. > Wouldn't this complexity, and the associated tables, better be incorporated in a system facility, such as an enhanced STCKCONV, eliminating the need for each application's developer to repeat the coding effort, and reducing the hazard of coding errors? One might invoke Unix System Services to perform much of the computation. Unfortunately, UNIX is ignorant of leap seconds, as required by POSIX specification of the standard functions (but this doesn't preclude extensions as an alternative). -- gil ---------------------------------------------------------------------- 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
