Strange output when using #stamp("29/01/2013") about stamp HOT 10 CLOSED

Stamp is outputting the 2-digit year, which is 13. I've been thinking about a couple ways to handle cases like this:

1. Disallow ambiguous examples. Stamp would raise an exception if an ambiguous value is encountered.
2. Implement a smarter language parser. Maybe a two-pass algorithm that would determine, on the second pass in this example, that '2013' is the year, so '01' must be the month.

Any thoughts?

from stamp.

Ahhh, I understand. So it seems that the issue came about here:

TWO_DIGIT_DATE_SUCCESSION = {
  :month => TWO_DIGIT_DAY_EMITTER,
  :day   => TWO_DIGIT_YEAR_EMITTER,
  :year  => TWO_DIGIT_MONTH_EMITTER
}

The first part was a day, so Stamp assumed the second part would be a year because it couldn't find any definite matches (right?). Maybe there's some room for improvement here; eg. if the day (previous_part) was two digits, and the current part is two digits, then expect the current part to be a month (unless it's obviously not, eg. if it's greater than 12). Just thinking out loud.

If nothing else, option 1 would work. I didn't realise I was giving Stamp ambiguous values until I went back over the docs.

from stamp.

Another example I just noticed:

1.9.3p286 :048 > Date.today.stamp '18/06/2012'
=> "04/13/2013"  # incorrect
1.9.3p286 :049 > Date.today.stamp '18/12/2012'
 => "04/02/2013"  # correct
1.9.3p286 :050 > Date.today.stamp '31/12/2012'
 => "04/02/2013"  # correct

from stamp.

@jeremyw I'd personally prefer solution 1 :)

By the way I ended up here because I had the same problem as @ghiculescu

> Date.today.stamp("30-03-2013")
=> "30-13-2013"

from stamp.

I think I prefer solution 1 as well but may not have time to tackle it soon. I'd love to see a pull request!

from stamp.

I'm looking into it, but I think we should agree on what we would consider ambiguous.
Raising an exception during translation instead of using TWO_DIGIT_DATE_SUCCESSION[previous_part] could be an easy way to prevent any ambiguous pattern but that would also kill legitimate ones currently working like "Jan 12, 1999".

from stamp.

By the way, I found a (bad) way to overcome this issue.

I've changed Stamp::Emitters::TwoDigit field from an attr_reader to an attr_accessor and then:

# emitters/composite.rb
result = ''
year_emitters = @emitters.select{|e| e.field == :year}
year_emitters.first.field = :month if year_emitters.size > 1
@emitters.each { |e| result << e.format(target).to_s }
result

Implementing some mechanism similar to TWO_DIGIT_DATE_SUCCESSION should two fields refer to the same date part would certainly help. By the way @jeremyw, with the above change all tests are green, but I'm not sure you want me to pull request something like that :)

from stamp.

Hi,

Just jumping in here because I had this idea a while back and just got around to looking it up on github to see if anyone had already done this. My idea was that you just learn a single date where all the parts are unambiguous, and I think the easiest to remember is Saturday 1st February 2003 16:05:06. Learning that one date seems easier to me than learning all the crazy date part constants crap.

Thoughts on the single date idea?

Also, as I'm not a Ruby guy I was thinking of implementing this in PHP and JS. Not really sure what the github protocol would be on that? Separate repos connected only by name?

from stamp.

@tomhicks I'm against the "golden date" idea just because you have to remember something specific, like the strftime directives. Don't let that dissuade you from trying to implement it, though. Just my opinion. :)

from stamp.

This issue is resolved in version 0.6.0. Thanks!

from stamp.