Quoting david at ruppconsulting.com, on Wed, Apr 26, 2006 at 09:23:25PM
-0600:> Sam,
>
> I''m using your vpim gem in my Rails project (thanks for writing
it!),
> and I discovered today that your extension of the Date class,
> specifically the to_time() method, shadows the same method in Rails.
> From what I can tell, the problem is caused by your use of the
> Time.at() method to convert seconds into a date; this method appears
> to work in UTC, where the Rails method uses Time.local(year, month,
> day) to create its date, and that creates the date in local time.
I''m
> in Colorado (MST/MDT), so that results in a -7:00 difference for me.
Hm, yes, I guess there are two ways of doing the conversion.
> I''m looking into some alternatives, like requiring the gem before
> Rails does its extensions to Date, or just patching my local copy of
> vpim, so it''s not critical or anything. I just thought you might
want
> to know about this potential conflict. Frankly, I''m surprised this
> kind of thing doesn''t pop up more often.
Me, too. I was doing it before rails, though, so I think rails should
use another method name, I got there first! :-)
Actually, its too easy to do this kind of thing in ruby, and I regret it
in retrospect. One problem is that ruby''s date and time classes
don''t
support everything I need, but replacing them is hard and causes interop
problems, because people expect to see a Time or a Date object, and
extending Date was easy.
As to how to fix it, I don''t know. Are you calling to_time, or is
rails?
If its just you, you could write a to_local_time method for Date, and
use that.
vPim only calls to_time in one place, I''ll see if I can fix that place.
Probably I need a Vpim::Methods.to_time(dateortime) method that does
what I need, and doesn''t pollute the method namespace for Date.
Thanks for the nudge,
Sam