> > Olson tz database uses 64 bit representation independently from time_t
> > size.
>
> My Debian Etch (i386) system uses TZif format (not TZif2 format).
>
> % strings -a /usr/share/zoneinfo/Asia/Tokyo|head -1
> TZif
>
> Is this file 64 bit representation?

Nope. Debian is really stable system.

> > Unfortunatly I haven't, and this is the biggest problem.
>
> I wrote a patch:http://www.a-k-r.org/tmp/ruby-big-time.patch
>

> Yes.  This is what I said at the last sentence of
> [ruby-core:22949].
> But why you add a timezone at first place?
>
> Assume a web based messaging system.
> Each user has timezone preference.
>
> User A sends a message to user B and C.
> User B see the date of the message in the timezone of B.
> User C see the date of the message in the timezone of C.
>
> In this scenario, timezone should be used at constructing
> the page for B and C.
>
> The timezone of A is not used.  No need to store the
> timezone of A in a Time object.
>
> It is enough to set a timezone at the last place.
> After the last place, Time object is used just for
> formatted and embedded for a presentation form.
> I.e. time calculations (Time#+, etc.) are not used after the
> timezone is set.  So time offset is enough for this purpose.

Okay, may be you are right. But I haven't understood purpose of your
patch. Can you give an example of problem which has been solved by it?
--
Pavel