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

[Jaap de Heer]

Hi Attila,

On Tue, Feb 09, 2010 at 10:47:28AM +0100, Attila Lendvai wrote:
> ok, i think this is the result of a bit of confusion in the code which
> i'll try to sum up now.
> 
> [...]
> 
> does it make sense? anybody full of fresh creative force and free time
> jumping up to implement it?

Makes sense to me, but in the mean time, what would be the
'closest to proper' behaviour of adjust-timestamp?
Nomenclature aside, what I find an important part of local-time
is the ability, given a 'date', to:

>  - set/offset any component of it, although what those
>  operations mean
> potentially depend on the mandatory calendar and the optional
> timezone
>  value in it.

With your assuming-utc patch, this becomes harder for non-utc
dates, since you would have to always explicitly specify the
timezone in every call, which makes *default-timezone*
not-really-so-default.
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*?

cya,
Jaap