John W. Baxter jwbnews at scandaroon.com
Tue Oct 3 13:27:09 EDT 2000

• Previous message (by thread): RFC: reimplementing the Type type as an extension type.
• Next message (by thread): range of mktime
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

---

In article <39D923A6.8A0A74B8 at uniserve.com>, bob van der Poel 
<bvdpoel at uniserve.com> 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

---

• Previous message (by thread): RFC: reimplementing the Type type as an extension type.
• Next message (by thread): range of mktime
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

---

More information about the Python-list mailing list