> YYYY-MM-DDTHH:MM:SS.NNNZ+09:30 > > How about mentioning that the time stamp must be a fixed > length, with leading zeros for padding. This makes parsing > and verification much simpler.
It sounds tempting, BUT... (see next paragraph). > > For example: time-secfrac SHOULD be 3 digits (milliseconds). > > Also, if sub second count is not used, it SHOULD be set to > 000 rather than making it optional. I oppose this: if we filled in a numerical value, the receiver would not be able to distingush between a device who's clock is accurate and who definitley says ".000" and another one which has just a second resolution and thus saying ".000". Thus, we would loose much in accuracy. I would definitly like to see the ms only from devices that actually support it. Otherwise, doing analysis, a process relying on the timeing could be totally fooled when correlating events (much can happen within a single second). Now, if you look at RFC3339, you'll see that you can't create a fixed format, with this in mind. The obvious choice of replacing the ".000" with ". " (being DOT SP SP SP) would violate RFC3339. > > The time offset should be in the format -0100 or +0930 (can > you tell I used to live in Adelaide). Alternatively a : could > be added in the middle -01:00 or +09:30. The HH:MM should be > fixed length and require the use of +/- indicator. RFC3339 specifies ":" and I see no reason to change things here - let's stick with the accepted standard (which says fixed size and '+/-'HH:MM). Rainer
