[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: ISO 8601 anyone?? And more on Parties.
Sharon Kadlec says "It's the CONTENT [of dates or times that's important], not the format - label it correctly and we'll put it where it belongs for our purposes." Absolutely! It's up to the recipient to interpret the normalized content - and then display the date, time or dateTime any which way he wants. Therefore, since a dateTime can always be normalized as an ISO 8601 extended date-time, there's no need to send along information on how to decode it. As I noted earlier, the spreadsheet catalog has "date time.format.text code" defined as "[Using] values from ISO 8601." There are no "codes" in ISO 8601. This isn't the same situation as with the EDIFACT C507 DATE/TIME/PERIOD composite where the date and time can be transmitted over the wire as DDMMYY or DDMMCCYY or CCYYMMDD or YYMMDDHHMMSS, etc. etc. With the dateTime XML Schema Data Type, you have no choice: it must be CCYY-MM-DDThh:mm:ss (with optional trailing - and unambiguous - time zone stuff or Z for universal time) - no 'ifs,' 'ands' or 'buts." Even putting aside the input format considerations, EDIFACT D.E. 2379 (Date or time or period format code) was used to indicate whether you had a Date, a Time, a DateTime, a Period,or a duration, etc. etc. - as to say: it was comingling data types. These are handled with separate datatypes in XML Schema: viz. a date (e.g., 1999-05-31), a time (e.g., 13:20:00), a dateTime (e.g., 2000-03-04T23:00:00+03), or a duration (e.g., P1Y2MT2H), respectively. These are conceptually separate basic core components (even dateTime could be considered basic - it needn't be merely a date and time aggregated together). William J. Kammerer FORESIGHT Corp. 4950 Blazer Pkwy. Dublin, OH USA 43017-3305 +1 614 791-1600 Visit FORESIGHT Corp. at http://www.foresightcorp.com/ "accelerating time-to-trade"
Powered by eList eXpress LLC