[#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:23035] Re: Ruby Time

From: valodzka <valodzka@...>
Date: 2009-03-27 14:43:07 UTC
List: ruby-core #23035
> 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))
> '
> #<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.
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
> #<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.

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.

In This Thread