About rubyspec\core\time\fixtures\methods.rb, we could change localtime to do
`#{BOOTSTRAP_RUBY_EXE} localtime.rb` where %BOOTSTRAP_RUBY_EXE% can be set to
point to some MRI version, and localtime.rb has a parallel implementation of
date.exe (assuming its straightforward). This would let us compare IronRuby
with MRI. Even if the patch is not accepted into RubySpec, we could
monkey-patch the localtime method form our default.mspec, but it does seem like
it would be useful even to MRI on Windows to make sure that it does not regress.
Another issue you might run into with the specs is that the fixtures change
ENV['TZ'] on the fly and MRI does not support it on Windows. See attached
email. If someone can confirm that ENV['TZ'] can be changed on the fly on
non-Windows platforms, we can open an MRI bug to track the issue, and then add
support to IronRuby to change ENV['TZ'] on the fly.
-----Original Message-----
From: ironruby-core-boun...@rubyforge.org
[mailto:ironruby-core-boun...@rubyforge.org] On Behalf Of
jirapong.na...@gmail.com
Sent: Tuesday, August 18, 2009 11:03 PM
To: ironruby-core@rubyforge.org
Subject: Re: [Ironruby-core] A couple of doubts (related to Time)
Hello Daniele,
About the DateTime in ironruby, you might encountered same problem
with me. The implementation in IronRuby use .NET DateTime struct which
unable to maintain reference id.
I was introduce RubyDateTime class to solve this problem, but
unfortunately i didn't have time to finish it yet.
My todo list:
RubyDateTime.cs
- Replace DateTime in the codebase
- Converter.IsIntegral might need to be
- override Equals, HashCode, and ToString (remember this is immutable
DateTime)
- Constructor as a DateTime
- Make it Serializable
- see msdn.com any other interfaces/attributes to propagate to
- define implicit operator converting from and to DateTime so that
Ruby code can pass a Ruby Time object to a CLR method that expects
DateTime.
- change comment "“Encapsulates DateTime and supports mutating of
instances (whereas DateTime is immutable)”
- Time#utc spec should be "modifies the receiver"
- fix for rfc2822 spec
You can find more info at -
http://ironruby.codeplex.com/WorkItem/View.aspx?WorkItemId=1021
Bests,
-Jirapong
On Aug 18, 2009, at 9:04 PM, Daniele Alessandri wrote:
> Hi,
> I encountered a few bugs in IronRuby while running the specs for
> rufus-scheduler (http://github.com/jmettraux/rufus-scheduler/). I'm
> fixing some of them right now, but in the meanwhile I bumped into a
> couple of issues running the rubyspecs for the Time class:
>
> * Time.at creates a dup time object with the value given by time
> See http://gist.github.com/169660 . The implementation of
> DateTime.Create(object, DateTime) returns a new DateTime created from
> self, but the two instances on the "ruby side" have the same
> object_id. I investigated a little bit more and noticed that there is
> only one DateTime element in the associated _valueTypeInstanceData of
> the current RubyContext. Well, no wonder: DateTime is a ValueType, the
> two values shares the same hashcode and _valueTypeInstanceData is a
> Dictionary<object, RubyInstanceData>. Honestly I don't think this
> poses any real problems, but still it is a different behaviour from
> the MRI. Thoughts?
>
> * Time.at converts to time object
> There was a bug in Time#at which got already fixed on my local
> repository, even so this spec is still failing. This time the problem
> is related to the rubyspecs: if you take a look at the the localtime
> method in rubyspec\core\time\fixtures\methods.rb (it returns the
> current local time from the OS), you can note that it works only for
> POSIX-systems. I can't think of a good and clean way to get this
> fixed, hope to hear Jim's thoughts about this one.
>
> Thanks,
> Daniele
>
> --
> Daniele Alessandri
> http://www.clorophilla.net/blog/
> http://twitter.com/JoL1hAHN
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core@rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core@rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core
--- Begin Message ---
I meant run with MRI…
On Windows, MRI might use the
_tzset<http://msdn.microsoft.com/en-us/library/90s5c885(VS.80).aspx> CRT
function which does not support changing ENV[‘TZ’] on the fly. Some of the Time
RubySpecs fail with MRI on Windows because the fixture setup sets ENV[‘TZ’]
which is very useful for testing. ActiveSupport tests also do the same.
From: Shri Borde
Sent: Monday, August 17, 2009 1:19 PM
To: Jimmy Schementi; Jim Deville
Subject: Can ENV[‘TZ’] be changed on the fly?
Could you run the following Ruby snippet on a Mac and let me know the output? I
get the output as shown in comments. I think that changing ENV[‘TZ’] is
supported only on non-Windows, but wanted to confirm before I open a bug for
supporting the same behavior on Windows.
cmd = "puts Time.local(2009).zone"
['PST', 'CST'].each do |tz|
ENV['TZ'] = tz
puts `ruby -e \"#{cmd}\"` # Prints two different values on Windows
end
['PST', 'CST'].each do |tz|
ENV['TZ'] = tz
eval(cmd) # Prints the same value on Windows since changing ENV[‘TZ’] on the
fly does not work
end
--- End Message ---
_______________________________________________
Ironruby-core mailing list
Ironruby-core@rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core
