[lkml]   [1998]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Y2K
       From: "Peter T. Breuer" <>
    Date: Tue, 23 Jun 1998 21:37:23 +0200 (MET DST)

    If my interpretation is correct, then this expression (1) will go weird
    at centuries that are not leap years, (2) doesn't sync by some number
    of leap seconds every year.

    Yes, but that's OK, because the 2000 *is* a leap year. (It's divisible
    by 100, but years which are divisible by 400 are an exception to the
    divisible by 100 rule, so while 1800 and 1900 were not leap years, 2000
    is a leap year).

    Are they trying to tell us that this number should be the number of
    real live (UTC) seconds since the epoch?

    No, what they're saying is that how you convert the number of real live
    (UTC) seconds since the epoch *to* tm_year, tm_mon, etc. That means
    that tm_sec will not necessarily be "correct" (it will be off by 14
    seconds at the moment, compared to wall clock time that does include
    leap seconds adjustments).

    In other words, the number of real live seconds since the epoch is the
    fixed point. time(0) is defined as returning the number of seconds
    since midnight January 1, 1970 (UTC). This has a well-defined meaning
    regardless of leap seconds. What POSIX in effect fudging is the
    converstion between time(0) and struct tm, since they're not including
    leap seconds in that conversion.

    Again, I'm not defending their decision (although I understand it); as I
    said earlier, there really is no good solution --- leap seconds really
    do screw a lot of things up.

    - Ted

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to

     \ /
      Last update: 2005-03-22 13:43    [W:0.021 / U:24.896 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site