[#22684] [Bug #1247] YAML::load converts some dates into strings — Matthew Wilson <redmine@...>

Bug #1247: YAML::load converts some dates into strings

10 messages 2009/03/05

[#22725] [Bug #1253] Fix MSVC Build Issues — Charlie Savage <redmine@...>

Bug #1253: Fix MSVC Build Issues

13 messages 2009/03/07

[#22727] Moving ruby 1.9.1 forward on windows — Charlie Savage <cfis@...>

Hi everyone,

14 messages 2009/03/08

[#22731] [Bug #1255] += for large strings egrigiously slow — James Lee <redmine@...>

Bug #1255: += for large strings egrigiously slow

11 messages 2009/03/08

[#22736] Ruby 1.9.1 and tail recursion optimization — =?ISO-8859-15?Q?Wolfgang_N=E1dasi-Donner?= <ed.odanow@...>

Moin, moin!

13 messages 2009/03/08
[#22739] Re: Ruby 1.9.1 and tail recursion optimization — =?ISO-8859-15?Q?Wolfgang_N=E1dasi-Donner?= <ed.odanow@...> 2009/03/08

Wolfgang N疆asi-Donner schrieb:

[#22748] [Feature #1256] Add constant TAILRECURSION to let a program recognize if tail recursion optimization is implemented — Wolfgang Nádasi-Donner <redmine@...>

Feature #1256: Add constant TAILRECURSION to let a program recognize if tail recursion optimization is implemented

7 messages 2009/03/08

[#22803] Relegate 1.8.6 to Engine Yard, part II — Urabe Shyouhei <shyouhei@...>

Hello and sorry for my being slow for this issue. It's OK now for me to pass

21 messages 2009/03/10

[#22812] [Bug #1261] cross-compiling Ruby extensions using mkmf doesn't fully respect DESTDIR — Daniel Golle <redmine@...>

Bug #1261: cross-compiling Ruby extensions using mkmf doesn't fully respect DESTDIR

8 messages 2009/03/10

[#22892] Ruby Time — valodzka <valodzka@...>

Got tired of current ruby Time limitation, I have written this -

24 messages 2009/03/14
[#22949] Re: Ruby Time — Tanaka Akira <akr@...> 2009/03/19

In article <9e19ed87-9d12-4f98-af3c-bd49a71b0bd4@p11g2000yqe.googlegroups.com>,

[#22974] Re: Ruby Time — valodzka <valodzka@...> 2009/03/20

[#22977] Re: Ruby Time — Urabe Shyouhei <shyouhei@...> 2009/03/20

valodzka wrote:

[#22981] Re: Ruby Time — valodzka <valodzka@...> 2009/03/21

> I bet you'll get tired of updating that database. There's a major difference

[#22893] [Feature #1291] O_CLOEXEC flag missing for Kernel::open — David Martin <redmine@...>

Feature #1291: O_CLOEXEC flag missing for Kernel::open

10 messages 2009/03/15

[#22939] [Bug #1303] A name considered a local variable on RHS of an assignment that defines it — Tomas Matousek <redmine@...>

Bug #1303: A name considered a local variable on RHS of an assignment that defines it

8 messages 2009/03/19

[#23063] [Bug #1332] Reading file on Windows is 500x slower then with previous Ruby version — Damjan Rems <redmine@...>

Bug #1332: Reading file on Windows is 500x slower then with previous Ruby version

11 messages 2009/03/30

[#23075] [Bug #1336] Change in string representation of Floats — Brian Ford <redmine@...>

Bug #1336: Change in string representation of Floats

37 messages 2009/03/31
[#23179] [Bug #1336] Change in string representation of Floats — Roger Pack <redmine@...> 2009/04/11

Issue #1336 has been updated by Roger Pack.

[#23181] Re: [Bug #1336] Change in string representation of Floats — Brent Roman <brent@...> 2009/04/11

[#23186] Re: [Bug #1336] Change in string representation of Floats — Yukihiro Matsumoto <matz@...> 2009/04/12

Hi,

[#23187] Re: [Bug #1336] Change in string representation of Floats — Brent Roman <brent@...> 2009/04/13

[#23188] Re: [Bug #1336] Change in string representation of Floats — Yukihiro Matsumoto <matz@...> 2009/04/13

Hi,

[ruby-core:23025] Re: Ruby Time

From: Tanaka Akira <akr@...>
Date: 2009-03-26 19:53:17 UTC
List: ruby-core #23025
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

In This Thread