Obvious next questions

Monday 11 August 2008 — This is 16 years old. Be careful.

Helping Max with DateDifference, we wanted a way to parse a date string using the user’s current locale. We naturally found the dateWithNaturalString:locale: method on NSDate. It sounds perfect. The documentation for the method includes this statement:

This method supports only a limited set of colloquial phrases, primarily in English. It may give unexpected results, and its use is strongly discouraged.

There’s an obvious next question here, and I wish the doc writer had thought enough about their reader to answer it: if this method’s use is strongly discouraged, what is the recommended way to solve my problem?

This isn’t meant to be a dig at Apple. There’s tons of reference documentation all over the place just like this. There are probably even tech writers that defend this style, in the name of modularity and brevity. Don’t believe it. This is unhelpful, exactly the opposite of what docs should be.

Extra bonus question: if you can help me understand how to parse dates according to the user’s current choices in the International system preferences panel, I would really appreciate it!

Comments

Dave St.Germain 7:47 PM on 11 Aug 2008

Did you try dragging an NSDateFormatter onto the text field? Then in the inspector for the formatter, choose "Mac OS X 10.0+" for the behavior and whatever you want for the date format to convert. You can type "today", "tomorrow", "2008/5/4" or whatever. I think it'll respect the locale.

Robert Kieffer 8:25 AM on 13 Aug 2008

Re: localized date parsing... have you tried Amazon's Mechanical Turk? ;)

Max Batchelder 9:56 AM on 13 Aug 2008

I tried the NSDateFormatter method but:
A) It doesn't seem to respect the locale (when I give it 6/7/08 it formats it to June 7 2008 even when I change my region to be UK) and
B) If I give it a time format to use, it requires a time be entered in the box, and if I don't give it a time format, it ignores times entered in the box.

I like the date formatter, and it seems like I'm going to end up using it somehow, but it needs to be more dynamic with the time format, or just use a dummy time if you don't specify one (currently if you don't specify a time, Date Difference uses 12:00:00), and it really needs to respect the user's locale, and preferably use their specified date formats...

Chris Lambacher 7:18 AM on 23 Aug 2008

For a web app I am working on we use a combination of python-dateutil and Babel:

from dateutil import parser
from babel.core import Locale
from datetime import datetime
class LocalizedParserinfo(parser.parserinfo):
    def __init__(self, locale):
        locale = Locale.parse(locale)

        # build up our list of words
        self.WEEKDAYS = [(locale.days['format']['wide'][i],locale.days['format']['abbreviated'][i]) for i in range(7)]
        log.debug(self.WEEKDAYS)
        self.MONTHS = [(locale.months['format']['wide'][i], locale.months['format']['abbreviated'][i]) for i in range(1,13)]
        log.debug(self.MONTHS)

        parser.parserinfo.__init__(self)

    def __call__(self):
        """ dateutil will attempt to call the passed in parserinfo object to instantiate it"""
        return self

def parse_date(date):
    locale = 'en'
    # this is how my app finds out the currently desired Locale
    if not identity.current.anonymous:
        locale = identity.current.user.Culture.replace('-', '_')
    return parser.parse(date, parserinfo=LocalizedParserinfo(locale), fuzzy=True, default=datetime.min)

Its far from perfect.

Obvious next questions

Comments

Add a comment: