Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

timestamp formatting differs on osx and linux #1

Open
richardmonette opened this issue Jan 4, 2014 · 3 comments
Open

timestamp formatting differs on osx and linux #1

richardmonette opened this issue Jan 4, 2014 · 3 comments

Comments

@richardmonette
Copy link

Hello, I wanted to report a potential issue when using Crazy Ivan on Linux (Ubuntu 13.10) vs. OSX (10.6.8).

On OSX I get (had a friend run the test since I dont have access to a OSX machine):

ruby 1.8.7 (2012-02-08 patchlevel 358) [universal-darwin10.0]

Last login: Fri Dec 27 15:14:12 on console
David-Mandias-MacBook-Pro:~ davidmandia$ irb

Time.now
=> Sat Jan 04 16:54:50 -0500 2014

and on Linux:

ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]

richardm@richardm-vbox:~/dev/crazy_ivan$ irb
irb(main):001:0> Time.now
=> 2014-01-04 13:38:03 -0800

I noticed the following comment in a generated index.html at line 214:

// Not sure why providing a 3-letter day trips up Date.js sometimes

My guess then, is that when doing something like:

Date.parse(timestamp.substring(4)).toString("HH:mm");

the intent is to remove the "Sat " so the Date.parse works. However, on Linux, it seems removing those 4 characters takes off the year, which causes the Data.parse to fail.

Does this seem to make sense?

Perhaps there could be a slightly more sophisticated check which sees whether the start of the data is characters, i.e. OSX style before removing them.

Please let me know if this seems to make sense, I'd be certainly happy to follow up with a patch to try and fix if you think I've identified a real issue here.

Thanks!

@edward
Copy link
Owner

edward commented Jan 19, 2014

@richardmonette Thanks for taking a look at this! It’s been a very long while since I’ve tinkered with this project. I think @wisq ended up maintaining a fork for a while longer, so I’d look at that one for reference.

I haven’t dug into the issue you bring up here too deeply, but offhand, I would say that if things are getting too complex with Ruby producing different Time.now output then I would find an API call that does the same thing across both versions. Something like Time.now.iso8601 should do the trick.

What do you think?

@richardmonette
Copy link
Author

Hey Edward, thanks for taking a look at this. Yes, I agree that it makes sense to fix this on the Ruby side of things. Switching to a standardized date format, as you suggest, would likely do the trick. I'll try and merge in @wisq's fork to see if the issue still exists there. If so, I'll try and put together a patch which addresses the issue as we've discussed.

@richardmonette
Copy link
Author

@edward So I merged in @wisq's changes - it appears he fixed the issue by adding a parseUTC function to the HTML templates (around line 203) as opposed to changing the values being fed from the Ruby side of things.

At this point, since it actually works, it may not be worth changing around.

That being said, I did a few updates (to this branch https://github.com/richardmonette/crazy_ivan/tree/iso8601DateFix) to try and get the tests running with the dependency versions on my machine, but had one stubborn test, test_runner_skips_already_tested_versions, which I've yet been able to get passing. It appears to be calling run_crazy_ivan twice, I presume the first time is to prime the already run versions. However, there is still a violation of the TestRunner.any_instance.expects(:test!).times(0) assetion, it seems test is being called even if the version has already been run.

I was curious, are you seeing the same test failure? I tried reverting out my date related changes, to try and rule out my introducing the error, but still seemed to get the same failure on that test case. At any rate, fun times messing around with the code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants