5

I have date as string in such format: 23 Nov. 2014. Sure, it's easy to convert this string into date with such expression:

Date.strptime(my_string, '%d %b. %Y')

But there is one issue when month is May - there is no dot, like 23 May 2014. And my expression breaks.

Could somebody help with this issue? How can I make universal expression for my cases?

Sergio Tulentsev
  • 226,338
  • 43
  • 373
  • 367
ktaras
  • 407
  • 4
  • 16

3 Answers3

3

Remove the period from my_string and from the date pattern.

Date.strptime(my_string.sub('.', ''), '%d %b %Y')

That's assuming you have at most one dot in my_string. If there may be several, use gsub.

Date.strptime(my_string.gsub('.', ''), '%d %b %Y')
Michael Laszlo
  • 12,009
  • 2
  • 29
  • 47
2

I think you're using the wrong method. Date#parse should work with almost "anything" (see TinMan answer and comment for clarification of when not to use parse) and provide the same object:

p Date.parse('23 Nov 2014') #=> #<Date: 2014-11-23 ((2456985j,0s,0n),+0s,2299161j)>
p Date.parse('23 Nov. 2014') #=> #<Date: 2014-11-23 ((2456985j,0s,0n),+0s,2299161j)> same object as with the previous line
daremkd
  • 8,244
  • 6
  • 40
  • 66
  • 2
    Date parse doesn't "work with anything", it's actually pretty limited, and slower, and prone to errors because of differences in common date formats between the U.S. and the rest of the world. Instead, use `strptime` for date formats you recognize, and maybe fallback to `parse`. The best thing is to know the user's LOCALE setting, or simply let them specify from a selection of alternates and use that. – the Tin Man Nov 23 '14 at 05:54
  • U.S. vs. the 'rest' of the world? I find that a rather elitist view. We're talking about an INTERNATIONAL date format here, if a specific country (like the US or any other) have their specific way of representing dates, then you can't tell that the parse method "doesn't work" just because it doesn't support some X country implementation. – daremkd Nov 23 '14 at 13:26
  • 1
    There's nothing "elitist" mentioned or implied. The most common U.S. date format is different and too many people are ignorant of that. Ruby, being an internationally-oriented language is doing it right. I think your politics are coloring how you read the comment. – the Tin Man Nov 24 '14 at 16:15
  • I've edited my answer to point to your comment/answer. I only care about objectivity, and I'm sorry if my comment reflected some political views (programming is one of the last places left where politics is not have a (major) influence and we all want it to stay that way). – daremkd Nov 24 '14 at 22:03
0

The parse method attempts to find matching date or date-time formats, then parse the string to return the values used to create a new Date or DateTime. There are many different formats it supports, which is convenient, however the process of scanning to find a match slows the parsing time.

Also, some formats in common use don't necessary "fit". Consider what's happening here:

Date.parse '31/01/2001'
=> #<Date: 2001-01-31 ((2451941j,0s,0n),+0s,2299161j)>

The date string in '%d/%m/%Y' (day, month, year) format is parsed, though it's not common in the U.S., because Ruby isn't a US-centric language. Reversing the first two fields results in:

Date.parse '01/31/2001'
ArgumentError: invalid date
  from (irb):4:in `parse'
  from (irb):4
  from /Users/greg/.rbenv/versions/2.1.5/bin/irb:11:in `<main>'
irb(main):005:0> Date.parse '31/01/2001'
the Tin Man
  • 158,662
  • 42
  • 215
  • 303
  • Yeah, I see, thanks! And I guess you also recommend me to remove period from the string and use `strptime`? – ktaras Nov 23 '14 at 13:36
  • 1
    You probably should normalize the string by removing the period. There are ways to work around that, but the period isn't a normal part of a three-letter month name. – the Tin Man Nov 24 '14 at 16:10