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