[local-time-devel] proper way to "travel in time"(?)

[Denys Rtveliashvili]

Hi Attila,

I am afraid, this method will not work as one might expect in some 
situations.
In case there is a shift in month or a year resulting in an invalid day 
of month, there will be an overflow.
For instance, a shift by one month back from the 31st of October, 2007 
will result in the 1st of October, 2007. So, the month will not actually 
change. Instead, it would be more natural to get 30th of September, 2007 
as a result.
I have made a small investigation in this matter and found that Java's 
GregorianCalendar class performs such kind of corrections and they are 
well documented.

I am going to try doing something like that myself and if the result is 
nice I will send it to this maillist.

Regards,
Denys Rtveliashvili

>> I've got one more question: is there any way to find shift the
>> local-time by minute/hour/day/month/year back and forth so that the
>> number of days in month and in year are taken into account
>> automatically? I see there is a function named "local-time-sum" but I do
>> not think it will do what I need. For instance, its results will be
>> weird if I try to shift the time stamp by one month.
>>     
>
> i think you should use decode/encode-local-time for this:
>
> (encode-local-time 0 0 0 0 40 01 2000) => @2000-02-09T00:00:00+01:00
>
> so, overflowing on the values is handled gracefully. this behaviour as
> an API is arguable, but this is how it works now. maybe we should
> eventually add a keyword arg to encode-local-time that tells whether
> to allow it or not...
>
> there's also local-time-adjust-days, it's basically what you need for
> days. the rest is implementable using encode/decode-local-time.
>
>