Unexpected behaviour when parsing an integer

[Duncan Bayne]

Currently, parse accepts an integer, and treats it as a string. In addition to this seeming strange (e.g. 45300 parses as 04:53), not all integers parse.

Those that in string form represent a valid time of day string do (e.g. 12:35) but those that don't, don't (e.g. 12:55).

Here's an interactive session demonstrating the behaviour, and in particular the annoying interaction with YML which parses times as integers:

[1] pry(main)> require 'tod'
=> true
[2] pry(main)> config = YAML.load(':tod: 12:35')
=> {:tod=>45300}
[3] pry(main)> Tod::TimeOfDay.parse(config[:tod])
=> #<Tod::TimeOfDay:0x00000001446708 @hour=4, @minute=53, @second=0, @second_of_day=17580>
[4] pry(main)> config = YAML.load(':tod: 12:55')
=> {:tod=>46500}
[5] pry(main)> Tod::TimeOfDay.parse(config[:tod])
ArgumentError: Invalid time of day string
from /home/duncan/.rvm/gems/ruby-2.2.3/gems/tod-2.0.2/lib/tod/time_of_day.rb:122:in `parse'

I'd like to submit a pull request to resolve this, but wanted to discuss a suitable resolution first.

I think the right thing to do is to have parse reject anything that isn't a string.

[Jack Christensen]

The reason for the to_s is to allow any string-like object to be parsed. I'm a bit nervous about changing this as it would be a breaking change for anyone relying on that behavior (though I don't think it has been documented -- duck-typing is common is Ruby -- so I wouldn't be surprised if people are implicitly relying on it). On the other hand bad data can ensue from parsing an int. So possibly this should be narrowed to to_str.

As far as YAML's unfortunate issues with times, I'm not sure we can do anything about that.

[Duncan Bayne]

Haven't had any opportunity to work on this for four years - shall we close it?

[Jack Christensen]

Will do.