FAQ
Using time.mktime() it appears that on my linux box the valid range is
1902...2038. Is this platform consistent, or, if not, is there a way to
determine at runtime the valid range?

Thanks.

--
Bob van der Poel ** Wynndel, British Columbia, CANADA **
EMAIL: bvdpoel at uniserve.com
WWW: http://users.uniserve.com/~bvdpoel

Search Discussions

  • Aahz Maruch at Oct 3, 2000 at 5:18 am
    In article <39D923A6.8A0A74B8 at uniserve.com>,
    bob van der Poel wrote:
    Using time.mktime() it appears that on my linux box the valid range is
    1902...2038. Is this platform consistent, or, if not, is there a way to
    determine at runtime the valid range?
    That surprises me mildly; the usual range is 1970 to 2038 (matching the
    range of the Unix 32-bit clock). You may want to use mxDateTime instead
    for greater range, precision, and utility.
    --
    --- Aahz (Copyright 2000 by aahz at pobox.com)

    Androgynous poly kinky vanilla queer het <*> http://www.rahul.net/aahz/
    Hugs and backrubs -- I break Rule 6

    There may or may not be a smiley above. --Aahz
  • Calvelo Daniel at Oct 3, 2000 at 9:18 am
    bob van der Poel wrote:

    : Using time.mktime() it appears that on my linux box the valid range is
    : 1902...2038. Is this platform consistent, or, if not, is there a way to
    : determine at runtime the valid range?

    Aahz Maruch reacted immediately:

    : That surprises me mildly; the usual range is 1970 to 2038 (matching the
    : range of the Unix 32-bit clock). You may want to use mxDateTime instead
    : for greater range, precision, and utility.

    It's 32-bit, but signed. The 32-bit-Unix-range is then 1970+/-68 years:
    a = 2L**32
    a/365/3600/24 # rough years
    136L
    2038-1970
    68

    HTH, DCA

    P.S. To answer the original question, I'm pretty sure that a 64-bit machine
    has 64-bit time_t. So I guess the range is not consistent across platforms.
    But then The Source Remains Unread.

    -- Daniel Calvelo Aros
    calvelo at lifl.fr
  • Fredrik Lundh at Oct 3, 2000 at 2:03 pm

    Daniel wrote:
    : That surprises me mildly; the usual range is 1970 to 2038 (matching the
    : range of the Unix 32-bit clock). You may want to use mxDateTime instead
    : for greater range, precision, and utility.

    It's 32-bit, but signed. The 32-bit-Unix-range is then 1970+/-68 years.
    note that the time.h functions use "(time_t) -1" to flag errors,
    so I doubt they expected anyone to use negative values...

    </F>
  • Bob van der Poel at Oct 3, 2000 at 3:52 pm

    Aahz Maruch wrote:
    In article <39D923A6.8A0A74B8 at uniserve.com>,
    bob van der Poel wrote:
    Using time.mktime() it appears that on my linux box the valid range is
    1902...2038. Is this platform consistent, or, if not, is there a way to
    determine at runtime the valid range?
    That surprises me mildly; the usual range is 1970 to 2038 (matching the
    range of the Unix 32-bit clock). You may want to use mxDateTime instead
    for greater range, precision, and utility.
    Thx for the pointer to mxDateTime. Found and dl'd it, looks very neat.
    I'll try using it later.

    --
    Bob van der Poel ** Wynndel, British Columbia, CANADA **
    EMAIL: bvdpoel at uniserve.com
    WWW: http://users.uniserve.com/~bvdpoel
  • John W. Baxter at Oct 3, 2000 at 5:27 pm
    In article <39D923A6.8A0A74B8 at uniserve.com>, bob van der Poel
    wrote:
    Using time.mktime() it appears that on my linux box the valid range is
    1902...2038. Is this platform consistent, or, if not, is there a way to
    determine at runtime the valid range?
    Test on a Mac to be sure what happens there. The native epoch there is
    Jan 1, 1904. (Ignoring Mac OS X.) So time is currently negative (when
    viewed as signed 32 bits, and the end of time is in 2040).

    (The modern Mac OS (from 1990 or so onwards) supplies 64-bit signed
    time, same epoch, and I believe "Carbon" removes the old 32-bit time.)

    --John

    --
    John W. Baxter Port Ludlow, WA USA jwbnews at scandaroon.com
  • Peter Hansen at Oct 4, 2000 at 3:51 am

    bob van der Poel wrote:
    Using time.mktime() it appears that on my linux box the valid range is
    1902...2038. Is this platform consistent, or, if not, is there a way to
    determine at runtime the valid range?
    Would reading the value in a loop until it wraps around be too much of a
    problem?


    :)

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedOct 3, '00 at 12:09a
activeOct 4, '00 at 3:51a
posts7
users6
websitepython.org

People

Translate

site design / logo © 2022 Grokbase