Kaushal Modi wrote:

> Sorry for your wasted time. It was my mistake.. I redefined current-time.

No problem. In penance you might want to take a look at the attached, which 
fixes a rounding error in that area that I noticed while looking into your report.

> hat value even though way in future is still valid, right?

Depends on the platform. It's not valid on platforms with 32-bit signed time_t; 
it is valid on almost every other platform.

It
> just happens that  (encode-time 0 0 0 21 12 2100) returns that 2 element
> time list.

Not if time_t is 32-bit signed.

> Is the issue with:
> - time list having 2 elements?
> - year being 2100?
> - Or the delta between that fake `current-time' and real current-time too
> big?

The issue is that encode-time returns a format that 
timer-next-integral-multiple-of-time does not grok. I'm not sure it's worth 
fixing this now, since we're about to change timestamp formats anyway and I'd 
rather not be twiddling much with the old one (it'll still be supported blah 
blah blah, I just don't want to be enhancing it).