So, under iOS8 (and, I presume, Yosemite, since this is about a foundation class) presents a number of deprecation warnings -- mostly things like constants who names have changed, when trying to compile the date formatter, e.g.:

ISO8601DateFormatter.m:216:86: warning: 'NSMonthCalendarUnit' is deprecated: first deprecated in iOS 8.0 - Use NSCalendarUnitMonth instead

These could be fixed by conditionalizing the code, but that will get very ugly instantaneously - is there a plan to address this in another way? Would it make sense to make a "modern" fork for people using iOS8/Yosemite and above?

I've go this issue, with no extra details.

There's a way to fix it, or avoid it?

1 libobjc.A.dylib objc_msgSend + 2
2 CoreFoundation -[__NSDictionaryM objectForKey:] + 128
3 MyApp -ISO8601DateFormatter dateComponentsFromString:timeZone:range:fractionOfSecond:
4 MyApp -ISO8601DateFormatter dateFromString:timeZone:range:
5 MyApp -ISO8601DateFormatter dateFromString:timeZone:

A test case in the Cocoa Touch test bundle target could and should post the notification that ordinarily the system posts in the event of a memory warning, in order to test that the ISO 8601 Date Formatter responds appropriately.

This class method would parse two ISO 8601 date strings and return whether they are equal.

Matters for debate:

• Should the parsing be strict?
• How exact should the comparison be? (Ideal, I suppose, would be detect how much information is in each string—e.g., whether one omits seconds—and accept equality within that level of granularity.)
• What options, if any, should be provided for customization of the comparison? (E.g., whether parsing is strict or not.)

Just curious why firstWeekday is set to 2 instead of depending on NSLocale or [NSCalendar currentCalendar].

The API should declare the nullability of method arguments, return types, and property values, and this should be enforced (where appropriate) in the tests.

Here is crash log:

0 libdispatch.dylib 0x1d3191be _dispatch_semaphore_dispose + 80 (semaphore.c:69)
1 Foundation 0x1e510b20 -[NSDateFormatter dealloc] + 74 (NSDateFormatter.m:291)
2 libobjc.A.dylib 0x1cee9258 objc_object::sidetable_release(bool) + 238 (NSObject.mm:1591)
3 ISO8601DateFormatter 0x0117e522 -[ISO8601DateFormatter stringFromDate:formatString:timeZone:] + 228 (ISO8601DateFormatter.m:716)
4 ISO8601DateFormatter 0x0117e3e6 -[ISO8601DateFormatter stringFromDate:timeZone:] + 132 (ISO8601DateFormatter.m:697)

When see code we are deallocating formatter but due to crash it's not going further steps where it's getting allocated.

if ([dateFormat isEqualToString:lastUsedFormatString] == NO) {
[unparsingFormatter release];
unparsingFormatter = nil;

	[lastUsedFormatString release];
	lastUsedFormatString = [dateFormat retain];
}

if (!unparsingFormatter) {
	unparsingFormatter = [[NSDateFormatter alloc] init];
	unparsingFormatter.formatterBehavior = NSDateFormatterBehavior10_4;
	unparsingFormatter.dateFormat = dateFormat;
	unparsingFormatter.calendar = unparsingCalendar;
	unparsingFormatter.locale = [[[NSLocale alloc] initWithLocaleIdentifier:@"en_US_POSIX"] autorelease];
}

Any inputs to fix this are welcome.

I'm updating my project to use Swift 3.0 and on 3.0 , NSISO8601DateFormatter becomes just ISO8601DateFormatter, which conflicts with this library.

Unfortunately, using ISO8601DateFormatter.ISO8601DateFormatter doesn't help either (seems to be a compiler bug: https://bugs.swift.org/browse/SR-1386).

An easy way to fix this would be using module_name in the Podspec (https://guides.cocoapods.org/syntax/podspec.html#module_name) to change the module to something else, allowing SomeModule.ISO8601DateFormatter.

Hey, your library is really interesting.

The only problem I found was the README.md, which lacks an Installation Section
I created this iOS Open source Readme Template so you can take a look on how to easily create an Installation Section
If you want, I can help you to organize the Readme.

What are your thoughts? 😄

Need to go from P1DT13H24M17S to NSTimeInterval and back. Or two NSDate's to time interval duration.

Relevant SO questions:
http://stackoverflow.com/questions/1146416/how-to-parse-an-iso-8601-duration-in-objective-c
http://stackoverflow.com/questions/22230629/how-to-transform-two-nsdate-objects-into-an-iso-8601-time-interval-duration

The existing plain-old-comment documentation isn't good enough anymore, particularly since I've discovered that http://cocoadocs.org/docsets/ISO8601DateFormatter/ exists.

It's time to start writing proper documentation that appledoc/CocoaDocs can read.

When using ISO8601DateFormatter with watchOS 2, then I get this error message when running pod install

[!] The platform of the target `XXXX` (watchOS 2.0) is not compatible with `ISO8601DateFormatter (0.7)`, which does not support `watchos`.

Please update the podspec for ISO8601DateFormatter to support watchOS 2.

Here's the Cocoapods blog entry: http://blog.cocoapods.org/CocoaPods-0.38/

These properties have existed since 10.7, so we should use them.

This would relieve any further need to use dateComponentsFromString:timeZone:. You'll get the time zone in the components.

New code added late in 0.8 has these already, but all code should have nullability where applicable (and const, where feasible).

Reported by Zac West via Twitter: https://twitter.com/zacwest/status/423243320626651136

STR welcome.

The dateComponentsFromString: methods fill in anything not specified by the string with the corresponding components from the current local date/time.

This is an artifact of the old, pre-NSDateComponents design. In the current design, it is broken behavior.

The components should not contain any information not directly sourced from the input string. Interpolation of missing components should happen in dateFromString:, if at all.

NSString* dateString = @"2012-04-01T15:37:53Z";

ISO8601DateFormatter *dateFormat = [[ISO8601DateFormatter alloc] init];
[dateFormat setIncludeTime:YES];
NSTimeZone *utcTimeZone = [NSTimeZone timeZoneWithName:@"UTC"];

NSDate* date = [dateFormat dateFromString:dateString timeZone:&utcTimeZone];

STAssertEqualObjects([dateFormat stringFromDate:date timeZone:utcTimeZone], dateString, nil, nil);

The above test fails with

'2012-04-01T16:37:53Z' should be equal to '2012-04-01T15:37:53Z'

Not sure why the NSString returned by the stringFromDate:date is 1 hour later since both dates are using UTC.

I'm still investigating the whys and wherefores (as I only saw this in a production app calling the API) but we've seen output like this occasionally:

2013-08-02T01:35:00 PMZ

It looks like its formatting the time as 01:30:00 PM then adding the 'Z' zone?

I'll update this ticket as we find out more information the code that produces the string is this:

    ISO8601DateFormatter *fmt = [[ISO8601DateFormatter alloc] init];
    NSTimeZone * tz = [NSTimeZone localTimeZone];
    fmt.includeTime = YES;

    if(self.timezone)
    {
        tz = [NSTimeZone timeZoneWithName:self.timezone];
    }


    return [fmt stringFromDate:self.created
                      timeZone:tz];

In the error seen above self.timezone was @"GMT" (which is what cocoa calls UTC) I don't know anything about the locale of the specific device but I believe that could have affected this.

Since 10.7, NSDateComponents has a nanosecond property. This would likely be friendlier to clients than the existing fractionOfSecond out-parameter.

tvOS support was added in a recent commit: 590e7cf and it would be very useful on my current project.

What is the time frame to get the new version of the pod published?

Long ago, I created the @ISO8601DateFormatter organization to host a mirror of this library in order to be used with CocoaPods. One of the constraints is that official pods need to point to tags, so I added that to the fork. It was only recently that I found this repo on GitHub.

I'd love to shut down my org and point the old specs to this. All it would take is for you to tag your commits thusly:

• 0.6 87068ab
• 0.5 8d0efbe
• 0.4 d357f89

I received this issue the other day on my project and it seems this problem occurs under OS X 10.11 & Xcode 7.1 with the framework.

Building the project with Carthage gives an error like it's unable to find destination and the destination was a Core Simulator iPhone 4S, iOS 9.1. I've checked the build settings of the ISO8601 framework target and the only thing unfamiliar to me is that the architectures were not set to Standard (armv7, arm64). I gave it a try setting it standard and it solved this issue.

I've created an issue, not a PR because I'm not aware of why do you have different settings for architecture, I would appreciate your help clarifying it. Honestly, I have no idea why does setting it to standard solve this problem if it worked perfectly under 10.10 and Xcode 7.0, couldn't find any useful information about it. It might even be a Carthage issue, I will ask them for help as well.

Currently, make test builds and runs a mess of shell, Python, and Objective-C code, which I've started referring to as the “test monsters”.

There are two test monsters. One of them does not even really test anything; it simply spews a bunch of output and leaves it to the person driving the machine to read it and scan for errors. (You tell me when the last time that actually happened was.) The other does test the output—using diff.

Now that we have (relatively) modern OCUnit-based tests, the test monsters should be slain.

This is blocked until all of the test cases worth caring about from the test monsters are ported over to OCUnit.

Once that's done, the test monsters should be killed off (and good riddance to them), and make test changed to run the Xcode tests.

I've noticed that the latest cocoapods spec for this library points to version 0.6 which is 2 years old now... Lots of things has been changed since that release :)

Usually a developer, who wants to add this library to his project via cocoapods will just add to Podfile:

pod 'ISO8601DateFormatter'

which will install 2 years old release...

Could you please mark some of the most recent stable commit with new tag? So we can add a new spec for this library to cocoapods.

Thanks in advance!

Hi,

Trying to compile this into a static library and run in both the simulator and Instruments (Xcode 5.0.2, iOS SDK 7) I get an undefined error. At the top of the .m file you conditionally include the UIKit.h (which, if included removes this problem) if TARGET_OS_IPHONE is defined.

To get this to compile for the simulator, I had to add "|| TARGET_IPHONE_SIMULATOR" to the condition.

Any idea how to get it to compile for instruments?

Hi,

I'm using this components to get a NSDate from a string obtained from Facebook API, but I found the NSDate is not right.

I tried the code bellow:

ISO8601DateFormatter* formatter = [[ISO8601DateFormatter alloc] init];
NSDate* date = [formatter dateFromString:@"2014-12-01"];
And I get the date as 2014-11-30 16:00:00 +0000, it's one day before 2014-12-01.

Yes, I'm in China, it looks right if we count the timezone element in.

But, I have tried other components on ISO8601, for example https://github.com/soffes/ISO8601
I tried the code the same as above, and I get the date as 1999-05-01 00:00:00 +0000

I have read the doc, didn't find any clue to get the same result as ISO8601 from this components.

Could you please teach me how to get a date as 2014-11-30 16:00:00 +0000 using this components?

Thanks in advance.

BR,
roby

Modern XCTestCase subclasses don't have headers unless they especially need them.

When I searched the CocoaPods site for this library, one result shows up.

Then I went and added it to my Podfile, ran pod install but I got the following error.
Unable to find a specification for iso-8601-date-formatter

Can you please implement CocoaPods support for your library? I'd really appreciate it.

Thanks.

Dependency "iso-8601-date-formatter" has no shared framework schemes

I know the project has merged Carthage support recently, maybe it's a regression?

I am getting crash report from the wild that has the following stacktrace.

0 ...    libsystem_kernel.dylib  __pthread_kill + 8
1    libsystem_c.dylib   pthread_kill + 58
2    libsystem_c.dylib   abort + 94
3    libc++abi.dylib     abort_message + 74
4    libc++abi.dylib     __cxa_pure_virtual + 18
5    libicucore.A.dylib  icu::TimeZone::getOffset(double, signed char, int&, int&, UErrorCode&) const + 54
6    libicucore.A.dylib  icu::Calendar::computeFields(UErrorCode&) + 76
7    libicucore.A.dylib  icu::Calendar::complete(UErrorCode&) + 42
8    libicucore.A.dylib  icu::Calendar::get(UCalendarDateFields, UErrorCode&) const + 28
9    CoreFoundation  _CFCalendarDecomposeAbsoluteTimeV + 240
10   CoreFoundation  -[__NSCFCalendar components:fromDate:] + 580
11   TestApp    ISO8601DateFormatter.m line 216
-[ISO8601DateFormatter dateComponentsFromString:timeZone:range:fractionOfSecond:]

This is a result of calling "dateFromString" with a string "2013-10-09T13:00:00Z". This does not crash all the time since I can see that it works for other dates in my logs.

I do however create an instance of ISO8601DateFormatter in my AppDelegate like the following.

(ISO8601DateFormatter*) iso8601DateFormatter {
  if (!_iso8601DateFormatter) {
    _iso8601DateFormatter = [[ISO8601DateFormatter alloc] init];
  }
  return _iso8601DateFormatter;
}

This works:
self.time = unboxer.unbox(key: "time", formatter: DateFormatter())

But this does not:
self.time = unboxer.unbox(key: "time", formatter: ISO8601DateFormatter())

Who knows what bugs it will catch?

https://github.com/boredzo/warnings-xcconfig

timeZonesByOffset is a global mutable dictionary accessed from multiple threads without synchronization, making independent date formatters unsafe to use from separate threads simultaneously.

This would enable smart editors/IDEs like AppCode to detect that, where a ISO8601DateFormat is expected, only those enumerated constants should be completed.

Unless I'm missing something, it appears that while the time zone is being set in the associated NSCalendar instance, it is the timeZone set in the NSDateFormatter instance which is actually being used to format the time. Since the passed-in time zone is used to append the "Z" or the numeric time zone offset, the actual time seen can be a mismatch with the time zone. It appears as though the systemTimeZone or localTimeZone is being used by default.

The following program will print out different time values, even though they both appear to be using a UTC time zone, and both end up with a "Z" time zone in the string. The NSDateFormatter result is correct; ISO8601DateFormatter prints out an incorrect time (unless actually being run in a zero-offset time zone).

#import <Foundation/Foundation.h>
#import "ISO8601DateFormatter.h"

int main()
{
    id pool = [[NSAutoreleasePool alloc] init];

    ISO8601DateFormatter *formatter = [[ISO8601DateFormatter alloc] init];
    [formatter setIncludeTime:YES];
    [formatter setDefaultTimeZone:[NSTimeZone timeZoneWithName:@"UTC"]]; // UTC

    NSDateFormatter *nsformatter = [[NSDateFormatter alloc] init];
    [nsformatter setDateFormat:@"yyyy-MM-dd'T'HH:mm:ss'Z'"];
    [nsformatter setTimeZone:[NSTimeZone timeZoneWithName:@"UTC"]]; // UTC

    NSDate *date = [NSDate date];
    NSString *isoFormatted = [formatter stringFromDate:date];
    NSString *nsFormatted = [nsformatter stringFromDate:date];

    NSLog(@"\nISO:    %@\nNSDate: %@", isoFormatted, nsFormatted);

    [pool release];
    exit(0);
    return 0;
}

The problem is fixed if you set unparsingFormatter.timeZone to the same value as unparsingCalendar.timeZone in the code.

This is running on MacOS 10.7; problem also observed using iOS 5.x.

The top of ISO8601DateFormatter.m imports UIKit.h, but nothing from this framework ever seems to be used.

It appears to have been added in a9b6973, and all usages removed in 98bf9cb.

E.g., ISO8601_NULLABLE should just be _Nullable.

On macOS 10.12 and iOS 10, Foundation has an NSISO8601DateFormatter class built in. It'd be cool if ISO8601DateFormatter wrapped that implementation when it's available, as an aid to clients who'd like to move toward that implementation.

Ingredients:

• Don't delete the existing implementation—clients supporting older OS versions will still need it.
• Ensure calls to ISO8601DateFormatter methods reach NSISO8601DateFormatter implementations when available. There are many ways you could achieve this: Return an NSISO8601DateFormatter from alloc; have a class cluster; return the result of the NSISO8601DateFormatter implementation at the start of each ISO8601DateFormatter implementation—up to you.
• NSISO8601DateFormatter property and method names may differ from those in ISO8601DateFormatter. Add methods with NSISO8601DateFormatter's names to ISO8601DateFormatter that call either the method of the same name on an actual NSISO8601DateFormatter (if possible) or the equivalent method in the ISO8601DateFormatter.

Hi Peter -

Thanks so much for your most excellent contribution of ISO8601DateFormatter to the Cocoa Open Source community. It definitely has to be one of the most widely used libraries floating around.

Several years ago I integrated the library into RestKit/RestKit and have been maintaining a forked version of the library ever since. We have made a number of incremental improvements to the package. We are currently in the process of atomizing some parts of RestKit into smaller more modular libraries and one of the sticking points at the moment is the dependence on the forked copy of the date formatter.

This has put me in the position of either a) shipping a standalone competing implementation of the date formatter or b) trying to integrate our changes back into the mainline so that there is one authoritative code base out there. I'd prefer to go the latter route and wanted to reach out and gauge your enthusiasm for larger changes to the library.

I'd like to do the following:

• Put an Xcode project on tree and integrate unit tests that aren't dependent on python / shell scripting.
• Put the project under Travis CI for continuous integration of the tests.
• Modernize the date formatter by updating it for ARC.
• Integrate whatever fixes I have in my codebase that have not appeared in your main line and add appropriate test coverage.
• Clean up the formatting and styling in use within the library to be more in line with modern idiomatic Cocoa.
• Improve the thread-safety of the library by factoring the parsing state out of the main class such that a new parsing operation object is created on each invocation.
• Refactor the parsing routines to be simpler to read and follow. The library has excellent support for the ISO date format standard, but is rather hard to follow.
• Mark up the source code with Appledoc

Let me know if this is of interest to you and you'd be willing to merge such changes. I am also happy to help you with on-going maintenance of the library.

It'd be nice if we could set up something to automatically build and run the modern tests after each push.

Mentioned as part of #21.

Hello,
I found out that stringFromDate doesn't respect time zone offset when date is in daylight savings time. For example, code:

    ISO8601DateFormatter * formatter = [[ISO8601DateFormatter alloc] init];
    formatter.defaultTimeZone = [NSTimeZone timeZoneWithName:@"Europe/Prague"];
    formatter.includeTime = YES;

    NSDate * date1 = [formatter dateFromString:@"2012-08-01T00:00:00+0200"];
    NSDate * date2 = [formatter dateFromString:@"2012-11-01T00:00:00+0100"];

    NSLog(@"1. Date 1: %@", date1); // just to be sure if date is OK
    NSLog(@"2. Date 2: %@", date2);

    NSLog(@"3. ISO8601 date 1 : %@", [formatter stringFromDate:date1]);
    NSLog(@"4. ISO8601 date 2 : %@", [formatter stringFromDate:date2]);

will produce wrong value at 3rd line:

1. Date 1: 2012-07-31 22:00:00 +0000
2. Date 2: 2012-10-31 23:00:00 +0000
3. ISO8601 date 1 : 2012-08-01T00:00:00+0100
4. ISO8601 date 2 : 2012-11-01T00:00:00+0100

I think that the fix is quite simple. You have to calculate GMT offset against the input date. Just change [timeZone secondsFromGMT] to [timeZone secondsFromGMTForDate:date];

After updating to iOS8 I've noticed that all of my dates are now coming back with the wrong date and time. For example this is the date string that I get from a web service "2015-01-15T18:30:00-08:00" and when I use:

ISO8601DateFormatter *formatter = [ISO8601DateFormatter new];
NSDate *date = [formatter dateFromString:inputString];
NSLog(@"%@", date);

The log shows the date as "2015-01-16 02:30:00 +0000" and then getting just the time from this NSDate gives me 6:30PM instead of 10:30AM (which is used to show before I moved to iOS8).

I can't tell if it's something on my side or with iOS8 and the library so I just figured i would put it here for now. Thanks.

Parsing a time-only string such as “T14:23-0800” will produce a string with the wrong date when the current local date is within the specified time zone offset from the next day UTC.

This is caused by #29. The underlying dateComponentsFromString: methods interpolate the current local date into the components, and dateFromString: then interprets those components in the specified time zone, creating a date that's a day too early (or, presumably, in some time zones, late).

Wasn't able to find an email address, lets try it this way.

Your blog gives an error:

Fatal error: __autoload() is no longer supported, use spl_autoload_register() instead in /home/public/blog/wp-includes/compat.php on line 502

https://boredzo.org/blog/

This is part of the modernization that is more broadly covered by #21.