[ruby-core:22991] Re: Ruby Time

> No, that's not all.  You then have to beg every single website on this planet
> installing ruby to update your library, every time that script runs.
On systems where tz database already installed (this is FreeBSD,
NetBSD, OpenBSD, DragonFly BSD, Mac OS X, most Linux  distributions,
BeOS, AIX and more [http://en.wikipedia.org/wiki/Tz_database]) library
can be easy configured on compilation time or runtime to use system tz
database, and after that thats's problem of OS maintainers. This
covers, I think, about 99% of systems. For others, yes, you should
publish announcement, but this can be also handled in automated mode.

> Your library cannot generate a time object representing
> Sun, 01 Nov 2009 01:30:00 EDT
>
> irb(main):001:0> require 'time2'
> => true
> irb(main):002:0> TimeZone.local "America/New_York"
> => #<TimeZone: Japan>
> irb(main):003:0> Time.local(2009, 11, 1, 1, 30, 0)
> => 2009-11-01 01:30:00 -0400
>
> Isn't it incomplete to say you can "get time in particular place" because we
> actually experience 1:30 in EDT?
Unfortunately, I haven't understood your example. Why it can't handle?
>> TimeZone.local  "America/New_York"
=> #<TimeZone: Europe/Minsk>
>> t = Time.local(2009, 11, 1, 1, 30, 0)
=> 2009-11-01 01:30:00 -0400
>> t.strftime "%a, %d %b %Y %H:%M:%S %Z"
=> "Sun, 01 Nov 2009 01:30:00 EDT"

>A time-with-offset strategy can handle this I believe.

Example. Two place, USA New York and Brazilia Manaus:
>> TimeZone.local "America/New_York"
=> #<TimeZone: America/Manaus>
>> t = Time.local(2009, 11, 1, 1, 30, 0)
=> 2009-11-01 01:30:00 -0400
>> t + 3600*24*30
=> 2009-12-01 00:30:00 -0500
>> TimeZone.local "America/Manaus"
=> #<TimeZone: America/New_York>
>> t = Time.local(2009, 11, 1, 1, 30, 0)
=> 2009-11-01 01:30:00 -0400
>> t + 3600*24*30
=> 2009-12-01 01:30:00 -0400
Can you see difference? The only way I see to handle this correctly -
time object should know that first place has DST and another - hasn't

> > 2) Time, except small range, remains unportable between different
> > platforms.
>
> That's unavoidable.  Time is, or at least has an aspect of, an interface
> between ruby and a platform.
That's unavoidable only in two places - requiring current time and
current time zone. Everything else can be handled (and has handled) in
library.
> PS: I cannot compile your library without modifications.
I am interested in any information.