-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Actually, the time_t problem only affects C and C++.  SQL uses a double to represent a time as days since the Epoch (Dec 31, 1899) with the fraction representing the fraction of the day (approx millisecond precision).  This method will work for well over 10,000 years +/-.  Java uses a similar structure for the Date class.  Most other recent languages (C#, Python, etc...) use similar structures as well.

If you're writing code in C, you can manage Date/Time values using the same type of structure, and only translate when calling an O/S API that requires time_t to eliminate most concerns.

The Y2K issue was there because so much COBOL code used fixed-width structures for dates (dates were generally strings).  Since time_t is a compiler-defined structure, simply changing the length of values in time_t and recompiling will "fix" nearly all C programs.


Bryan.ONeal@asu.edu wrote:
> I have never writen a mortgage calculator that used a date in the calculations.
>  Though I have used date refrances as a convenance when using calender
> interfaces.  But the beautiful thing about calculus is that you do not ahev to
> have algebraic equations that requier such fine graned intstriment like seconds.
>  You simply intergrate on accross each payment cycle with continuiously
> compaoinded intrest.  Though I have used date functions in MySQL and Java that
> were and I always check for integrity past 2038 and ensure all leapyears are
> handled corectly untill 2500. 
> 
> But again, I'm just an accountant...
> 
> Quoting Victor Odhner <vodhner@cox.net>:
> 
> 
>>Jason <jason@spatafore.net> wrote:
>> > The article did touch on a serious issue: What
>> > about mortgage calculations past 35 years from
>> > today? The point is: What about prediction today
>> > for the limitations of tomorrow?
>>
>>I agree that anyone using an application that has
>>to look past 2038 would do well to use appropriate
>>test cases today, both to smoke-test the program and
>>to sanity-check the results.
>>
>>This type of computation should not rely on system
>>utilities that deal with the current date and time
>>in terms of seconds.  That is not a "bug for Linux",
>>it's just lazy programming.  But I'm sure a lot of
>>these programs were written in COBOL and have
>>survived Y2K; and I bet most of them do their own
>>OS-independent decimal arithmetic in terms of
>>days, not seconds.
>>
>>Our mortgage will be over in three years!  ;-)
>>
>>Vic
>>---------------------------------------------------
>>PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
>>To subscribe, unsubscribe, or to change  you mail settings:
>>http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>>
> 
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change  you mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCfj2jz97zWS+k+hcRAq44AJwJf6YaVu18gc/lC5h67R4H2vd0DgCfThTg
AnrjWE+hA2GUc9cCQp4ooXY=
=9SGN
-----END PGP SIGNATURE-----
---------------------------------------------------
PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change  you mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss