Date Format Specifiers (ISO 8601)

Hi all,

Background: I'm working on building a lightweight (microcontroller platforms) DateTime builder class that accepts various flavors of dates and times and assembles a formatted string, depending on the client/service selected format specifier.

I'm using this link as my point of reference:
http://support.sas.com/documentation/cdl/en/lrdict/64316/HTML/default/viewer.htm#a003169814.htm

If either of these duration specifiers are chosen:

• $N8601B
• $N8601E

there appear to be a few possible resulting formats:

• PnYnMnDTnHnMnS
• -PnYnMnDTnHnMnS
  
• PnW (weeks)

The first and second appear to be explicable: one DateTime could precede the other, and vice-versa.

How do I determine whether the third is the desired format? There's at least another ambiguous specifier, so should I come to rely on them, or just resort to using the ISO 8601 notations themselves?

Seems you would be able to check if there is a 'W' in the entry. If so then weeks.

So pretty much I'd just rely on the format itself and the specifier would be okay to be omitted outright?

I am not sure if I am following. I can see taking in the input, examining it for the format keywords, and kicking off what ever functions appropriately afterwards.

I skimmed that link and the examples had a 'W' in there so that looks to be the path of least resistance.

I worked it out - was overthinking the whole thing.

Regular expressions will be your friend here to determine the format returned. I would have to know what language exactly you are doing the checks in to give an example of how to match those formats.

That's probably too costly of an approach for the real-time stuff I'm working on (or perhaps any). A precious few kilobytes of memory would be burned, a lot of blocking code introduced, and so on.

For this, I ended up defining a 'DateTime' class that strictly does its work upon integral data types (most of the work) and another class 'DateTimeBuilder' with functions that each implement a statically defined format that gets written to a 48-byte buffer (whenever display of time is needed). It was tedious, but it performs and is still portable.

This might be more of an "academic" question than practical, but it's been bugging me.

With my custom DateTime class, if my date is Feb 29 on a leap year, and the year is adjusted to a non-leap year, what correction should take place:

• Maintain month, decrement day
• Increment month, set day to 1
• Maintain month, set day to 1
• Assume the worst and reset the rest of the date to Jan 1
• Set a flag within the object to indicate an invalid date and leave it up to caller to correct
• Ditch all that, use a single unsigned 64-bit integer to store the DateTime seconds since Epoch, re-compute accumulated value for any year/month/day/hour/min/sec update, and derive those fields each time a setter/getter is called? (and maybe use separate millisecond and microsecond fields to track timestamps on applicable systems?)

Set a flag within the object to indicate an invalid date and leave it up to caller to correct

Click to expand...

This. It's not the consumer class's job to fix, in any myriad of ways, the data.. but to validate and act on it. Otherwise that's some mixing burdens issue.