From: valodzka Date: 2009-03-27T23:43:07+09:00 Subject: [ruby-core:23035] Re: Ruby Time > 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. This can be autoconfigured of course. > Also, if time2 supports out of time_t, the timezone db in OS > is not useful. Olson tz database uses 64 bit representation independently from time_t size. > 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. Unfortunatly I haven't, and this is the biggest problem. > 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)) > ' > # > 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. This can be solved by marshaling both, time zone name and offset. If we have problem with time zone name - we can use offset. > > As the previous example, time2 find "Japan" timezone as > # 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. I doubt if 0.18 second per process is a big problem. And this can be avoided by setting TZ enviroment variable. > 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. I can imagine it, but it will be possible only with exotic systems. > 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. There are one main problem with offset: it isn't fixed for fixed place (example with new york and manaus here http://groups.google.com/group/ruby-core-google/msg/f00c55f56482fc73), and I don't known how to solve it.