:04 PM
To: Multiple recipients of list ORACLE-L
Subject:RE: year 2059 problem
This is not true for all versions of VMS of 4.7+, whether on a 64-bit Alpha
or 32-bit VAX. The standard VMS date is (was?) an 8-byte quadword whose
value is relative to a base date of November 17, 1858
As I recall from my trip to Nepal, there are several calendars in use. In
fact, we celebrated 2 separate New Years. I joke that I left Nepal 64 years
older than when I arrived!
-Original Message-
Sent: Monday, December 30, 2002 6:56 AM
To: Multiple recipients of list ORACLE-L
UNIX store
This is not true for all versions of VMS of 4.7+, whether on a 64-bit Alpha
or 32-bit VAX. The standard VMS date is (was?) an 8-byte quadword whose
value is relative to a base date of November 17, 1858 (Julian Day 240 --
Smithsonian Astrophysical Observatory's day "zero") and is accurate until
Hi
I have just tested with 2037 on a linux (2.4.18) with rdbms 9.2.0.2 and this
works.
Lyndon Tiu wrote:
Hmmm, anyone tried Linux Oracle with year 2059?
--
Lyndon Tiu
On Sunday 29 December 2002 08:28 pm, Amit Nargotra wrote:
This strange problem we are facing while implemting
UNIX stores time as amount of seconds passed since
the 1st of January 1970.
Since it is 32-bit value in modern Unices, it can
hold up to 2,147,483,648 or
approximatively 68 years. The
counter overflows on 19th of January 2038 at
3:14:07 AM. People believe that all the hardware
will be 64-bi
Hmmm, anyone tried Linux Oracle with year 2059?
--
Lyndon Tiu
On Sunday 29 December 2002 08:28 pm, Amit Nargotra wrote:
> This strange problem we are facing while implemting Oracle Based ERP at
> Nepal for asian paints.
>
> Nepal follows Hindu calender, as per the hindu calender the current year
