So I was working on File, but that had a few routines which returned
Time
objects, so I started a sidetrack on that which took a little longer
than I
expected. I have most of it complete (except for strformat) implemented
as
an extension to the .net Date/DateTime class.
I’ve also integrated the Rubinius Time specs into the test project with
some
hiccups. Almost half of the tests are passing, with the bulk of the
failures due to the specs use of the “ENV” object to set the time zone
before testing out the Time class. Personally I think that monkeying
with
the system clock isn’t a great test idea anyway, and I don’t know of a
good
cross platform way to handle it.
So what do you suppose I should do here?
- Implement new tests that are more portable (I doubt I have time to
work
out Rubinius’ commit/patch requirements)
- Just disable the tests that use ENV
- Implement new tests just for IR
Thanks!
Eric
Eric N. wrote:
don’t know of a good cross platform way to handle it.
So what do you suppose I should do here?
- Implement new tests that are more portable (I doubt I have time to
work out Rubinius’ commit/patch requirements)
- Just disable the tests that use ENV
- Implement new tests just for IR
Please don’t implement tests that target a specific implementation,
especially for core classes. Spend the time to make the tests work
everywhere.
For what it’s worth, though, ENV is required by lots of apps and
script in Ruby. You’re going to need to have it working anyway. As for
time-zone tweakage…anything that’s a side effect of setting ENV should
probably be modified.
You should also talk to the rubinius guys about how to run the specs
such that they filter out things IR might never support.
23 of the tests fail with MRI/CRuby as well due to the ENV[:TZ] thing,
although that number may be higher or lower if you are in a different
time
zone… I suppose the tests could be rewritten with a lookup table of
timezones and test values.
The JRuby tests are significantly better with just 2 of 49 tests failing
on
MRI/CRuby (missing strftime features), but time zones aren’t really
tested
at all. That seems like the most reasonable approach to me: test with
gmt
for specific dates and localtime for generic “today” type tests. But
you
will have to trust that the localtime logic is implemented correctly on
your
system.
JRuby tests depend on minirunit right now which doesn’t run under IR.
It
needs at least the IO class implemented, and unfortunately I put my name
beside that one on the wiki. Doh!
-Eric
On 10/26/07, Curt H. [email protected] wrote:
Having said that, the TZ environmental variable is a UNIXism; do these
tests pass for CRuby under Windows at all?
No. They run without throwing an error, but there is no effect on date
processing due to setting ENV[:TZ] on a windows system so the tests that
use
it all fail unless you are coincidentally in the correct time zone.
-Eric
On 10/26/07, Eric N. [email protected] wrote:
23 of the tests fail with MRI/CRuby as well due to the ENV[:TZ] thing,
although that number may be higher or lower if you are in a different time
zone… I suppose the tests could be rewritten with a lookup table of
timezones and test values.
Echoing what Charlie said, if ENV[“TZ”] is a common-enough convention in
Ruby then IronRuby should implement this value.
Having said that, the TZ environmental variable is a UNIXism; do these
tests
pass for CRuby under Windows at all?
Eric N. wrote:
processing due to setting ENV[:TZ] on a windows system so the tests that
use it all fail unless you are coincidentally in the correct time zone.
That’s one issue with the Rubinius specs; nobody’s developing Rubinius
on Windows, so those tests are probably never being run there.
On JRuby, I know we have at least one core dev on Windows, but we’re not
a whole lot better. The community helps though, at least for reporting
lots of Windows bugs none of us want to fix.
On 10/26/07, Eric N. <[email protected] > wrote:
No. They run without throwing an error, but there is no effect on date
processing due to setting ENV[:TZ] on a windows system so the tests that use
it all fail unless you are coincidentally in the correct time zone.
Sorry… I just realized you said this in your previous post.
I’ve done enough Googling to see that there are at least some people who
expect that setting ENV[“TZ”] from within Ruby will affect the
values returned by certain of Time’s methods – despite this not working
under the standard (?) build for Windows.