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

From: Tanaka Akira <akr@...>
Date: 2009-03-29 10:01:03 UTC
List: ruby-core #23057
In article <eb859ef1-94e9-472f-ab23-19d9f00154a7@j39g2000yqn.googlegroups.com>,
  valodzka <valodzka@gmail.com> writes:

>> > 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?

My patch just change internal representation to relax the
representable range.

With the patch:

  % ./ruby -e 'p Time.utc(2**100)'
  1267650600228229401496703205376-01-01 00:00:00 UTC

Without the patch:

  % ruby -e 'p Time.utc(2**100)'  
  -e:1:in `utc': bignum too big to convert into `long' (RangeError)
          from -e:1:in `<main>'

No timezone/offset related extension yet.

I think Time.mktime should take optional 8th argument,
offset, as
Time.mktime(year, mon, mday, hour, min, sec, usec, offset).

offset can be a number or a string such as "+09:00".
:std and :dst may also be accepted for tm_isdst for
mktime().

If people needs timezone abbreviations really, 9th argument
may be extended.  It is just for Time#zone, etc.  Not used
for time calicurations.
-- 
Tanaka Akira

In This Thread