[local-time-devel] non-intuitional behavior of adjust-timestamp and timezones

[Attila Lendvai]

> I still wonder, what does assuming utc in adjust-timestamp get
> us? If the user wants utc, he can just specify it in the call, or
> set *default-timezone* to utc.
> Is this patch the first step of phasing out *default-timezone*?

no. what i wrote up in my previous mail is the result of a short
brainstorming that happened just now. and even if i started working on
this, i'd still keep two specials: *timezone* and *calendar* as the
default values of their &key counterparts (having 'default' in the
name is superfluous imho).

the problem fixed by my change is that if you have a loop that goes
trough each month using (adjust-timestamp (offset :month 1)) then it
means different things in different timezones, and currently we are
representing dates as timestamps with zero senconds in the UTC zone.

this all seems more and more kludgey to me now, including our way of
representing dates... :/

having a differently broken behavior of adjust-timestamp is not really
a good option, but it is at least 'backward compatible'... :) so, i've
recorded a rollback of my change. we have our own branch, i can delay
pulling that patch over to us...

does it get you the results you expect?

-- 
 attila