Jamey Cribbs wrote:
> Nope.  It's not going to work on windows.  You can always force the 
> value in
> the YAML file to be a string by prepending it with !str, and then you 
> can
> convert it however you want in your script.

Well, in this case I have no control over how the yaml file gets 
created...

This just seems to me to be a bad design decision somewhere. Why would 
YAML use Time.gm to deserialize rather than DateTime given the fact that 
Time.gm behavior is so system-dependent?!

What I ended up doing to work around this temporarily was get a hold of 
the pure ruby yaml library, RbYAML, and hacked the timestamp code to use 
DateTime.parse instead of Time.gm - I haven't finished fully testing it 
yet and I may be missing some kind of big issue as well, but it seems to 
work at the moment.

This, in concert with the Rails ActiveSupport Date/Time/DateTime core 
extensions gives me some ability to work with timestamps in a fairly 
interchangeable fashion but... honestly, this kind of thing sucks! 
Having two seemingly similar timestamp classes just leads to confusion, 
especially with those new to the language! The fact that their APIs 
aren't similar doesn't help matters, as that must end up dictating which 
to use in some cases... IMO, DateTime and Time objects should be fully 
interchangeable!
-- 
Posted via http://www.ruby-forum.com/.