|
>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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.