Using NSDateFormatter on the iPhone, protect locale but lose date components.

Question

Hi

This is a slightly tricky question. I am using NSDateFormatter on the iPhone but I wanted to only show a standard date without the years component. But retain the users locale formatting for their date.

I could easily override the formatting using

[dateFormatter setDateFormat:@"h:mma EEEE MMMM d"];  // hurl.ws/43p9 (date formatting)

But now the date is in my in en-nz format eg 12:01PM Wednesday July 7. So I have totally killed the locale for any other users around the world.

I would like to say.

Give me the correct localized date for this users region but omit the years component.

Since the date is being displayed as string, I am tempted to just fromat the date and then remove the year component by just cutting this out of the string.

Answer 1

You could try something like:

//create a date formatter with standard locale, then:

// have to set a date style before dateFormat will give you a string back
[dateFormatter setDateStyle:NSDateFormatterMediumStyle];

// read out the format string
NSString *format = [dateFormatter dateFormat];
format = [format stringByReplacingOccurrencesOfString:@"y" withString:@""];
[dateFormatter setDateFormat:format];

Kind of a hack, but it should work.

Edit: You may want to remove occurrences of the strings @"y," and @" y" first, in case you end up with some funky extra spaces or commas.

Answer 2

The problem with the answer above is that @"y," and @" y" are both localization dependent. I just played around with setting the date and time format on my computer to Japanese, Korean and a number of other formats. You'll find that sometimes the year is represented by a symbol in the local language, or sometimes a period is used, or a number of other possibilities. So you'd need to search and replace all those possibilities as well, if you hope to maintain correct localization dependence.

There is a class method +dateFormatFromTemplate:options:locale: which may help, although it doesn't take date or time style and so it's not as flexible.

I'm not sure that there is a good solution with additional APIs from Apple. But even then it's not clear that they have their own localizations separated out into components. Without out that, this is essentially an impossible task.