RE: With the upcoming time change.... -- MIDRANGE-L

I recall someone posting that one systems vendor changed the system clock to
speed up or slow down until the clock had moved forward or back by one hour.
It seems a reasonable way to get around the problem of "reliving" that extra
hour when we "fall back".  Time based logs would still be linear.  I suppose
that workload estimators would go nuts trying to understand how 180%
utilization for that hour could have happened... <g>

Eric DeLong
Sally Beauty Company
MIS-Project Manager (BSG)
940-898-7863 or ext. 1863



> -----Original Message-----
> From: Bruce Vining [mailto:bvining@us.ibm.com]
> Sent: Friday, October 25, 2002 9:41 AM
> To: midrange-l@midrange.com
> Subject: RE: With the upcoming time change....
>
>
>
> >Now that I've stuck my foot out there to be smashed, I'll
> have a look at
> >the archives and see what the discussion included. But I'll
> tell you now
> >it'll be very hard to convince me that this sort of change isn't an
> >improvement that's well worth the effort.
>
> I (speaking for myself of course) would tend to agree that this would
> represent an improvement and be worth the effort.
>
> Points such as running the system clock on a UTC basis,
> having the system
> automatically recognize local conventions such as daylight
> savings time,
> having current time interfaces continue to return local time while new
> interfaces provide UTC time, having the system clock value
> maintained using
> established methods such as SNTP, etc. all seem like
> worthwhile objectives.
>
> And having the ability to define whether or not a particular system
> recognizes daylight savings time could take care of special
> cases such as
> Indiana and/or situations where one didn't want an automatic
> time shift due
> to daylight savings at say 2 in the morning (that is, wait
> until the system
> activity is low/safe at 4:30 and then change the daylight savings time
> attribute to yes).
>
> Interesting thoughts for sure,
> Bruce
>
>
>
>
>                       "Booth Martin"
>                       <Booth@MartinVT.co        To:
> <midrange-l@midrange.com>
>                       m>                        cc:
>                       Sent by:                  Subject:  RE:
> With the upcoming time change....
>                       midrange-l-admin@m
>                       idrange.com
>
>
>                       10/25/2002 08:39
>                       AM
>                       Please respond to
>                       midrange-l
>
>
>
>
>
> --
> --
> [ Picked text/plain from multipart/alternative ]
>
> If you're going this far why not allow the Operating System
> to call home
> for
> a correct time?  OS/2 did that long ago.
>
>
>
> ---------------------------------------------------------
> Booth Martin   http://www.MartinVT.com
> Booth@MartinVT.com
> ---------------------------------------------------------
>
> -------Original Message-------
>
> From: midrange-l@midrange.com
> Date: Friday, October 25, 2002 08:52:12 AM
> To: midrange-l@midrange.com
> Subject: RE: With the upcoming time change....
>
> Hi, Vern:
>
> Thanks for your message. That's fair at first glance. So
> we're saying we
> can't improve the operating system because we have vendor
> Business Partners
> who have special considerations, and it's our duty to protect
> them, thereby
> ensuring that they don't have opportunity to remove those special
> considerations? That's an interesting proposal indeed!
>
> What if this was all *planned* and IBM were to state, "From
> VxRx forward,
> the AS/400 will use GMT as its internal time of reference. All times
> presented to the user will be *local,* having been adjusted
> according to
> the user-specified UTC offset *TABLE* which is DST-aware."
> (This is not a
> new concept... it's been on *nix systems, for example, for at
> least thirty
> years.) Now, if IBM were also to allow (say via API) an application to
> reference GMT (and the table in some fashion), the BP in
> question would be
> (or at least should be) able to work off of that internal
> clock, thereby
> eliminating such special operations once and for all. And
> what if (wonder
> of wonders) the USER had the choice of specifying a fixed
> UTC-offset (ala
> Indiana or China or ....), and would therefore be able to
> operate the tired
> old way if s/he so chose?
>
> As I read it, the thinking is "ApplicationX requires special
> steps in order
> to accomodate DST. In order that we don't disrupt things and take away
> ApplicationX's need for those special steps once or twice
> every year, we
> can't touch the code." And we can't improve it for those who don't use
> ApplicationX because ... umm ... because ... Am I missing something?
>
> Now that I've stuck my foot out there to be smashed, I'll
> have a look at
> the archives and see what the discussion included. But I'll
> tell you now
> it'll be very hard to convince me that this sort of change isn't an
> improvement that's well worth the effort.
>
> I know that I'm way past "Everybody else has one, Mom. Why
> can't I?" but
> come on, IBM.
>
> Dennis
> --
> [ IMSTP.gif of type image/gif deleted ]
> --
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion
> (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
>
>
>
>
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion
> (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
>