In article <deab6882-12ac-4aa1-a901-681795ed863b / z9g2000yqi.googlegroups.com>,
  valodzka <valodzka / gmail.com> writes:

> Problem discussed in thread even in current implementation can be
> handled by setting one variable ($__tz_path) from ruby.

It solves the maintainance problem.  Good.

However, it needs a configuration for $__tz_path.
No configuration is much better.

I don't think all Ruby user configure it.

Also, if time2 supports out of time_t, the timezone db in OS
is not useful.  So you may wish time2 installs it's own
timezone db.  But it causes the maintainance problem again.
It seems you have a plan for that.

There is no such problem if we store a time offset (not
timezone) in Time object, even if we extend Time to support
out of time_t.

I found marshal forget the timezone in time2:

% ../bin/ruby -Ilib -rtime2 -e '
p TimeZone.local
t = Time.local(2000).localtime(TimeZone["US/Pacific"])
p t
p Marshal.load(Marshal.dump(t))
'
#<TimeZone: Japan>
1999-12-31 07:00:00 -0800
2000-01-01 00:00:00 +0900

It seems time2's Marshal.load uses the local time.

Basically, marshal preserves the object.
So someone may request to preserve the timezone by marshal.

But it is a difficult problem.

If timezone name is marshaled with the time, the timezone
may not exist at Marshal.load because timezone database is
OS dependent.  (using $__tz_path is assumed.)
For example, some OS (GNU/Linux) provieds "Japan"
timezone but some other OS (FreeBSD) don't provide it.

If timezone data itself is marshaled, it may be obsoleted
between Marshal.dump and Marshal.load due to DST rule change
and leap second determination.  It is possible if the
marshaled data is stored in a file/DB.  It is difficult to
update the marshaled timezones in a file/DB.

There is no such problem if we store a time offset (not
timezone) in Time object because a time offset is easily
marshalled as a number and it will not be obsoleted.

As the previous example, time2 find "Japan" timezone as
#<TimeZone: Japan> in my environment.  This is interesting
because it is difficult to know the current timezone name.

It seems that time2 scans the timezone directory.  It needs
many open system call.  It makes Ruby slow.

% time ../bin/ruby -Ilib -rtime2 -e 'Time.now'
../bin/ruby -Ilib -rtime2 -e 'Time.now'  0.14s user 0.06s system 99% cpu 0.202 total
% time ../bin/ruby -Ilib -rtime2 -e 'Time.now'
../bin/ruby -Ilib -rtime2 -e 'Time.now'  0.14s user 0.06s system 98% cpu 0.199 total
% time ../bin/ruby -Ilib -rtime2 -e 'Time.now'
../bin/ruby -Ilib -rtime2 -e 'Time.now'  0.13s user 0.06s system 98% cpu 0.199 total

% time ruby -e 'Time.now'        
ruby -e 'Time.now'  0.02s user 0.00s system 95% cpu 0.021 total
% time ruby -e 'Time.now'
ruby -e 'Time.now'  0.02s user 0.00s system 91% cpu 0.022 total
% time ruby -e 'Time.now'
ruby -e 'Time.now'  0.02s user 0.00s system 94% cpu 0.021 total

time2 has ~0.18 sec overhead.

Also, even if a timezone is found, it is possible that it is
not exactly same as the system timezone.  For example, time2
can't use the system timezone directly on a OS which don't
use Olson time zone database.  If the timezone with time2 is
different from the system timezone, Ruby behaves
inconsistently to all other programs (except PHP and
PostgreSQL?) on the OS.

There is no such problem if we store a time offset (not
timezone) in Time object because it doesn't need timezones
other than the system timezone.

I think multiple timezone support should be separated as
external library.

I guess it will be used to personalize a date in web
applications.  If so, timezone library can be used at
constructing a web page.  I don't see a necessity that Time
object refer a timezone.
-- 
Tanaka Akira