re #347 Add a system-level keyword to specify that COSMOS should glob…

[donaldatball]

…ally use UTC times.

Note to reviewer: Under the hood, this implementation uses a monkey patch to the Time class so that Time objects created with new, now, and at are set up to be local or UTC depending on the system setting. I know touching core classes that way is a scary proposition, but this was the only way that I could come up with to consistently apply a Time Zone setting all across COSMOS. Another option would maybe be to derive a special CosmosTime class, but that seems like it'd be a lot of search'n'replace work, and hard to enforce usage in the future.

[coveralls]

Coverage decreased (-0.05%) to 85.751% when pulling 46d605e on system_time_zone into 9abc903 on master.

[ghost]

Unfortunately can't monkey patch core Time methods without almost certainly breaking other ruby libraries. Will have to change to the massive search/replace option.

[donaldatball]

@ryanatball

Fair enough, I figured this was pretty risky (although I did learn a lot).

A couple possible ideas:

1. Create CosmosTime (better name?) class derived from Time; constructor, now, and at functions overridden (instead of overwritten). Replace all Time objects with CosmosTime objects.
   or
2. Add .sys (better name?) function to core Time.class, operates on self. Replace Time.now with Time.now.sys, throughout the system (also Time.at with Time.at.sys, Time.new with Time.new.sys).

It feels like the first option is more likely to be correct in all cases. Do you have a preference? Or is there a better way that I'm not thinking of?

[ghost]

Probably the CosmosTime option. I think you may need to make some more changes to the new() method as well. The changes you've made change how time will be formatted into a string, but not how time is entered. For example .new seems to always accept entry in local time units (probably needs to change to accommodate entry from UTC?). Also .at() always takes entry in UTC (probably should NOT change).

[coveralls]

Coverage decreased (-0.03%) to 85.771% when pulling 996823f on system_time_zone into 9abc903 on master.

[donaldatball]

@ryanatball

This should be ready for review now. I ended up going with the .sys() function in the Time class for a few reasons:

1. It's the same amount of search'n'replace work, but less code elsewhere (i.e. just a couple functions in Time.rb as opposed to a whole new CosmosTime.rb file).
2. I started feeling that it'd be better to have all of our hacks to the Time class in one place, so someone that's looking through our core_ext folder will see everything we've done.
3. Even though it worked ok with respect to the UTC/local settings remaining consistent, it was weird having objects start out as CosmosTimes and then change back to regular Times-- now they're all just Time objects all the time.

[ghost]

👍 Looks great Donald.