Re: Time change questions !
- From: Dave Froble <davef@xxxxxxxxxxxxx>
- Date: Sat, 04 Nov 2006 16:14:53 -0500
Neil Rieck wrote:
"Richard B. Gilbert" <rgilbert88@xxxxxxxxxxx> wrote in message news:3v6dnS3OYfDBg9HYnZ2dnUVZ_qWdnZ2d@xxxxxxxxxxxxxxStephen Hoffman wrote:[...snip...]
The phrase "inner mode applications" seems to me to more of an oxymoron than "military intelligence".
I doubt if this mess is ever going to be rewritten in a "more logical and strightforward manner". I just wish that more thought had been given to the subject 30 years ago. For the forseeable future it will just be one of those few things that Unix does better. At least the VMS time keeping scheme can keep going till 31-DEC-9999 if anybody still cares then. Unix is going to have severe problems later this century unless some fairly drastic changes are made.
Yep but in 2038 I'm going to be 86 (provided I'm 6 feet above ground rather than 6 feet below) and no one is going to be listening to the old guy mumbling "We told them so".
:-)
If memory serves, the 2038 problem can be pushed off to 2106 if programmers only switch from a signed to unsigned "seconds since 1970-01-01".
That was my best solution to the word based date from the RSTS environment. Treating it as an unsigned word gets you to 2035. Still a bit short of the Unix problem.
Note that as far as I know DEC/Compaq/HP didn't embrace this solution in the Basic compiler and it's date functions. I had to write routines to handle the unsigned word integer. That did cause a 'conversion' effort. Minor in comparison to any other possible solutions.
###
Right now OpenVMS doesn't have any near-term date limitations so only the time (zone) thing needs to be fixed in order to make it as good as UNIX. So what are our options?
1) HP won't make any changes because they don't want to break anything and they want to save money.
2) This means that third party developers will need to step up to the challenge like they did 20 years ago with TCP/IP. (for example, TCPware first appeared in 1984)
3) Hopefully, there will be enough support that HP would eventually license the third party code for integration into the OpenVMS code base. Even then, it would be nice to enable this functionality on a per process basis (like $SET PROC/CASE and $SET PROC/PARSE)
4) If there wasn't ever enough interest in this from HP, some third party developers are going to be raking in a lot of easy money for a long time to come.
Neil Rieck
Kitchener/Waterloo/Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/links/cool_openvms.html
Some possibilities.
First, to avoid breaking things, leave the system date alone, but, provide additional functionality for those who want it, that will use the system date and the UTC offset to calculate a UTC date.
Second, provide a mechanism for a process based date and time, and routines that build off what the above speculated routines do, to support the process date and time.
Such would bring date and time usage out to the application level, and VMS could support both, the original dates, and the application specified dates.
Possibly some parameters to specify what's being used, which system utilities could respect.
Just my initial thoughts on the issue.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@xxxxxxxxxxxxx
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
.
- References:
- Re: Time change questions !
- From: prep
- Re: Time change questions !
- From: Stephen Hoffman
- Re: Time change questions !
- From: JF Mezei
- Re: Time change questions !
- From: Dave Froble
- Re: Time change questions !
- From: Richard B. Gilbert
- Re: Time change questions !
- From: Stephen Hoffman
- Re: Time change questions !
- From: Richard B. Gilbert
- Re: Time change questions !
- From: Neil Rieck
- Re: Time change questions !
- Prev by Date: Re: Itanium model numbers {re F$getsyi("HW_MODEL")}
- Next by Date: Re: Time change questions !
- Previous by thread: Re: Time change questions !
- Next by thread: Re: Time change questions !
- Index(es):
Relevant Pages
|
