Issue #3 new

Conversion fails using AM/PM

Anonymous created an issue

I'm using this on iOS and finding that it worryingly gives the wrong results. If I convert the following string;

2011-09-09T06:30:47 PM+100

The resultant NSDate is actually 2011-09-09 05:30:47 AM +0000 when described. That's a whole 12 hours of error!

Comments (9)

  1. Anonymous

    I should add that the input string was generated using this library as well ... just in case it's the source that is invalid!

  2. Anonymous

    Hi Peter

    I had a class reference which created the strings like this;

    +(NSString *) dateToISO8601:(NSDate *) date {
    
        ISO8601DateFormatter *formatter = [[ISO8601DateFormatter alloc] init];
        formatter.includeTime=YES;
    
        return [formatter stringFromDate:date]; 
    }
    

    This creates bogus strings unless I change the format string. I have also added in 2 other changes to ensure that the AM/PM setting does not impact things. In -(NSString *) stringFromDate:formatString:dateFormat:timeZone: I have added the line;

    // Force the locale to 24 hour time to remove the AM/PM
    [formatter setLocale::[[[NSLocale alloc] initWithLocaleIdentifier:@"en_US_POSIX"] autorelease]];
    
    NSString *str = [formatter stringForObjectValue:date];
    etc ...
    

    And I have done the same in the weekDateStringForDate:timeZone: function immediately after the formatter is created in the if (includeTime) block.

    I haven't tested which of these is fixing my use case, and I was very surprised that there seemed to be no tests for the time at all, which makes me think there could be lots of other bugs lurking in here as well. However for my own use case, these 3 changes have fixed it.

  3. Peter Hosey repo owner

    I tested that alternate fix and it does not work.

    I'm starting to think it's a Foundation bug. As far as I can tell from the printf(3) manpage, I should be able to use + and 0 together (and I'm pretty sure this used to work).

  4. Peter Hosey repo owner

    New pull request that should hack around the problem: https://bitbucket.org/boredzo/iso-8601-parser-unparser/pull-request/2/bug-with-timezone-offset-format

    As far as I can tell, what the code does now is correct according to both the C standard and the Mac OS X printf(3) manpage. I think Apple broke it at some point. Either way, the result is broken, and I doubt we can all just wait for Apple to fix it.

    I'll probably accept the pull request later, after I test it.

  5. Peter Hosey repo owner

    Actually, I'm going to move the time-zone offset thing to a separate ticket. The AM/PM issue, which I still need STR, is something different.

  6. Peter Hosey repo owner

    I changed my system time format to 12-hour and could not reproduce this. All my unparsing tests pass, including times in the latter half of the day.

    Please include a full test program that reproduces the problem, and tell me what specific version (i.e., revision hash) of the ISO 8601 date formatter you used and what your locale identifier is if you don't change it.

  7. Log in to comment