Date problem: -d

[Manfred Lotz]

On Sat, 03 Sep 2005 23:55:39 -0700
Bryan O'Sullivan <bos at serpentine.com> wrote:

> On Sat, 2005-09-03 at 23:28 -0700, Bryan O'Sullivan wrote:
> 
> > I've just committed a fix.
> 

Thanks a lot. That worked fine.


> I'm not completely satisfied with the first fix I committed, by the
> way, even though it's much better than nothing.
> 
> Python relies on the underlying platform's runtime for some
> time-related routines.  Unfortunately, on some platforms, time_t is a
> 32-bit quantity, while on an increasing number, it's wider (on an
> x86_64 box running Linux, for example, the max you can feed to
> time.localtime is 0xf0_c2ab_7c55_19fb, because a struct tm's year
> field is a signed 32-bit quantity).
> 
> This means that if you create a commit time that's bigger than 32 bits
> on a 64-bit machine, a 32-bit machine will explode when attempting to
> render that commit in commands like log and diff.
> 
> A more correct time validation, for now, is to check if abs(time) <=
> 0x7fffffff.
> 

Wouldn't it be better to allow a more human readable time format
(e.g.; Sun Sep  4 08:57:32 2005 +0200) which internally gets converted
to the required formats?




-- 
Manfred