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
>
---------------------------------------------------
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
(text/plain)