 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Programming / Mac Programming / July 2005CoreData date format
Wow! An hour with CoreData, and already a working app. Pretty impressive. I'm looking at the XML store file, and the date format is confusing. I thought it would be base-64 encoded NSDate in iso 8601. There's something else going on. The content of the attribute seems to vary with the formatter used with the attribute, which is odd. Why not store in one flavor? > I'm looking at the XML store file, and the date format is confusing. I > thought it would be base-64 encoded NSDate in iso 8601. There's something > else going on. The content of the attribute seems to vary with the > formatter > used with the attribute, which is odd. Why not store in one flavor? Do you really see different formats within the same XML file? I only encountered this issue when dealing with a parser for XML and binary plists. AFAIK XML plists use RFC3339 to encode the date. In Binary plists the date uses an 8 byte (big endian) double which represents the number of seconds relative to relative to 1 January 2001 00:00:00 GMT (take a look at CFAbsoluteTime; http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFDatesAndTim es/index.html). Hope this helps. CU, Udo Thank you ! > > I'm looking at the XML store file, and the date format is confusing. I >> thought it would be base-64 encoded NSDate in iso 8601. There's something >> else going on. The content of the attribute seems to vary with the formatter >> used with the attribute, which is odd. Why not store in one flavor? > Do you really see different formats within the same XML file? Not within the same file, per se. I changed formatters, and the content changed dramatically. It's possible it could be an aberration, since I didn't actually document specific dates' content, but it certainly looked different. I can take a closer look > I only encountered this issue when dealing with a parser for XML and > binary plists. [quoted text clipped - 4 lines] > look at CFAbsoluteTime; > http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFDatesAndTim es/index.html). Okay, it certainly _looks_ like a relative seconds thing; deltas between consecutive days are the number of seconds in a day, so that settles that. Negative numbers and all for older dates. So are we to assume that the XML store uses this standard, and not ISO 8601 as I've been lead to believe? All the googling I've done says it's 8601. > Hope this helps. > > CU, > > Udo > Not within the same file, per se. I changed formatters, and the content > changed dramatically. > It's possible it could be an aberration, since I didn't actually > document specific dates' > content, but it certainly looked different. I can take a closer look Could you give an example? > it certainly _looks_ like a relative seconds thing; deltas between > consecutive days > are the number of seconds in a day, so that settles that. Negative > numbers and all for older > dates. According to CF-368.11\NumberDate.subproj\CFDate.h CFAbsoluteTime is indeed a second offset: [...] typedef double CFTimeInterval; typedef CFTimeInterval CFAbsoluteTime; /* absolute time is the time interval since the reference date */ /* the reference date (epoch) is 00:00:00 1 January 2001. */ [...] This is also confirmed if you take a lookt how an CFAbsoluteTime is obtained in CF-368.11\NumberDate.subproj\CFDate.c: [...] CFAbsoluteTime CFAbsoluteTimeGetCurrent(void) { CFAbsoluteTime ret; #if defined(__MACH__) || defined(__svr4__) || defined(__hpux__) || defined(__LINUX__) struct timeval tv; gettimeofday(&tv, NULL); ret = (CFTimeInterval)tv.tv_sec - kCFAbsoluteTimeIntervalSince1970; ret += (1.0E-6 * (CFTimeInterval)tv.tv_usec); #elif defined(__WIN32__) FILETIME ft; GetSystemTimeAsFileTime(&ft); ret = _CFAbsoluteTimeFromFileTime(&ft); #else #error CFAbsoluteTimeGetCurrent unimplemented for this platform #endif return ret; } [...] > So are we to assume that the XML store uses this standard, and not ISO > 8601 as I've > been lead to believe? All the googling I've done says it's 8601. We both were right. I just doublechecked ("[...] read the source Luke!") and found this (in CF-368.11/PropertyList.dtd): <!ELEMENT date (#PCDATA)> <!-- Contents should conform to a subset of ISO 8601 (in particular, YYYY '-' MM '-' DD 'T' HH ':' MM ':' SS 'Z'. Smaller units may be omitted with a loss of precision) --> This is of course ISO 8601 (although "just" a subset) .... but also perfetcly valid RFC3339 (subset as well). This subset avoids all the subtle details of ISO8601/RFC3339 (fractional milliseconds ... ) .... but will allow me to use a much simpler parser than my full blown RFC3339 parser :-). CU, Udo |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.