[CESG] CCSDS 301.0-B-4 propsed pink sheet (Time Code B) / Backward compatibility?
Mario.Merri at esa.int
Mario.Merri at esa.int
Fri Aug 5 07:44:55 UTC 2016
Peter,
my proposal would be:
1. No change is needed to accommodate Erik's request as this is already
foreseen by the standard
2. Improve the text in the standard to make the rules for subsetting
clearer.
For 2. for instance, it is implicit and possibly open to interpretation
that, regardless whether one removes subsets from the left or from the
right, this must be done on contiguous subsets and one cannot take out for
example "mm" and have YYYY-DDDThh:ss (although I admit not very
meaningful). In other words to the left or to the right of what? I know,
it is a little bit pedantic, but CCSDS should strive for fully unambiguous
text. My proposal here is to further refine the text of clause c and add
the exhaustive list of allowed subset formats.
I am also a little bit puzzled by the fact that the "Z" terminator is
declared optional. I guess the logic is that the parser will consider the
time code finished when it encounters a character different from a
numerical digit. What if, to save bits, the next field that happens to be
numeric is collapsed to the time code? Wouldn't be cleaner to make "Z"
terminator mandatory if the time subset is present?
Regards,
__Mario
From: "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov>
To: "Mario.Merri at esa.int" <Mario.Merri at esa.int>, "Barkley, Erik J
(3970)" <erik.j.barkley at jpl.nasa.gov>
Cc: "cesg at mailman.ccsds.org" <cesg at mailman.ccsds.org>
Date: 04/08/2016 23:42
Subject: Re: [CESG] CCSDS 301.0-B-4 propsed pink sheet (Time Code
B) / Backward compatibility?
Hi Mario,
I’m not clear what you are proposing. In one paragraph you say that the
standard is “ok”. In the next paragraph you say that the standard forces
use of ICDs because it is ambiguous. Which is it? And, if you think it
is a problem, just what would you propose to change?
I agree that this could probably be stated even more clearly, but, as you
point out, it does provide both a clear specification of the full set of
sub-fields and rules for dropping sub-fields if they are not needed. If
you had quoted the complete text of sec 3.5.1.3.c you would see the
following:
c) Calendar or time subsets may contain all the defined subfields, or may
be abbreviated to the span of interest by deleting the unneeded subfields,
either on the left or on the right. However, when subfields are deleted on
the LEFT, all separators that had delimited the deleted subfields must be
retained (except for the ‘T’ which, by rule b, is dropped if the subset is
used alone.) When subfields are deleted on the RIGHT, the separators that
had delimited the deleted subfields are dropped. ?
Between this rule (and the other three in Sec 3.5.1.3), the explicit use
of required separators and the rules for keeping or dropping them, it is
possible to construct a simple but robust parser that will not have any
ambiguities. In fact, any parser that is supposed to be compliant with
this spec that has a problem with parsing any truncated calendar, or time,
or combined “calendarTtime” format would have to be judged non-compliant
with the spec.
According to the rules any of the following constructs should be
acceptable:
YYYY-DDDThh:mm:ss.d→dZ
YYYY-DDDThh:mm:ss.d→d
-DDDThh:mm:ss
-DDDThh:mm
hh:mm:ss.d→dZ
YYYY-DDD
Perhaps a non-normative set of examples like this would have helped?
Thanks, Peter
From: CESG <cesg-bounces at mailman.ccsds.org> on behalf of Mario Merri
<Mario.Merri at esa.int>
Date: Thursday, August 4, 2016 at 1:52 AM
To: Erik Barkley <erik.j.barkley at jpl.nasa.gov>
Cc: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org>
Subject: Re: [CESG] CCSDS 301.0-B-4 propsed pink sheet (Time Code B) /
Backward compatibility?
Hi Erik,
I believe your proposed change is not needed as it is already covered by
the standard, in particular by clause 3.5.1.3.c. In fact, there it is
clearly stated that:
[...] time subsets [...] may be abbreviated to the span of interest by
deleting the unneeded subfields, either on the left or on the right. This
implies that one can delete the "d→d" subfield
When subfields are deleted on the RIGHT, the separators that had delimited
the deleted subfields are dropped. This implies that one can delete the
decimal dot
·
For the decimal dot I believe the current solution is OK. Robust
implementations should parse the time code string until they find the "Z".
If they find a "." before, then the time has decimal fraction of second.
On the other hand, clause 3.5.1.3.c provides full flexibility to eliminate
any subfield. This seems to me not clean and not in the spirit of
standardisation as it results in the proliferation of different time
formats, which require specific ICDs to make them unambiguous.
Regards,
__Mario
From: "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov>
To: "Barkley, Erik J (3970)" <erik.j.barkley at jpl.nasa.gov>
Cc: "CESG -- CCSDS-Engineering Steering
Group\(cesg at mailman.ccsds.org\)\(cesg at mailman.ccsds.org\)"
<cesg at mailman.ccsds.org>
Date: 04/08/2016 05:04
Subject: Re: [CESG] CCSDS 301.0-B-4 propsed pink sheet (Time Code
B) / Backward compatibility?
Sent by: "CESG" <cesg-bounces at mailman.ccsds.org>
I agree. I think clause 3.5.1.3.c covers this case (and even the hh:mm
case). I just hope that implementations are robust enough to handle it
correctly.
Peter
Sent from Peter's iPhone 6
Everything should be made as simple as possible,
but not simpler.
~Albert Einstein
On Aug 3, 2016, at 6:34 PM, Barkley, Erik J (3970) <
erik.j.barkley at jpl.nasa.gov> wrote:
Gippo,
I too noted that it might be possible to interpret 3.5.1.3 as already
allowing removal of the decimal fraction/sub-second.
CESG members,
What is your taking/reading on this? Does this already allow fractional
seconds to be optional? If not, why not?
Best regards,
-Erik
From: Gian.Paolo.Calzolari at esa.int [mailto:Gian.Paolo.Calzolari at esa.int]
Sent: Monday, July 25, 2016 2:26 AM
To: Barkley, Erik J (3970) <erik.j.barkley at jpl.nasa.gov>
Cc: CESG -- CCSDS-Engineering Steering Group (cesg at mailman.ccsds.org) (
cesg at mailman.ccsds.org) <cesg at mailman.ccsds.org>
Subject: Re: [CESG] CCSDS 301.0-B-4 propsed pink sheet (Time Code B) /
Backward compatibility?
Erik,
from a purist point of view I think that it would be incorrect
stating that the change is backward compatible as a former implementation
would expect to find always the "Decimal fraction of second" and would
most likely crashes when that field is absent.
Conversely a constant setting to 0 when not used would be fully backward
compatible.
However it is also true that despite section 3.5.1.2 "ASCII TIME CODE B,
Year/Day of Year Calendar Variation" defines only one optional field (i.e.
the time code terminator) section 3.5.1.3 "SUBSETS OF THE COMPLETE TIME
CODES" basically allows many fields to be optional so I wonder whether it
would be more correct working on section 3.5.1.3 instead of adding the
optional field in section 3.5.1.2.
In other words, the part of 3.5.1.3 clause (c) stating that the code "may
be abbreviated to the span of interest by deleting the unneeded subfields"
does already allow removing the Decimal fraction of second subfield?
My cent.......
Gian Paolo
PS It looks to me that the sentence "the need to accommodate the upcoming
century rollover in only 11 years" was somehow wrong in 2010 as it is now
:o)
From: "Barkley, Erik J (3970)" <erik.j.barkley at jpl.nasa.gov>
To: "CESG -- CCSDS-Engineering Steering Group (
cesg at mailman.ccsds.org) (cesg at mailman.ccsds.org)" <cesg at mailman.ccsds.org>
Date: 22/07/2016 01:44
Subject: [CESG] CCSDS 301.0-B-4 propsed pink sheet (Time Code B)
Sent by: "CESG" <cesg-bounces at mailman.ccsds.org>
CESG Colleagues,
Attached is the proposed pink sheet for Time Code B which makes the time
code more suitable for such applications as publishing a standardized
schedule of services for which mandatory fractional seconds is
meaningless. (By the way does anyone know what the original rationale was
for requiring, at a minimum, 1/10 of second time statements?) The
proposed change is the addition of “(optional)” which is in keeping with
the method by which optional is designated for the “Z” character in the
recommendation. I believe the “.” subfield separator disappears of by
application of 3.5.1.3 clause (c). If this change is made to Time Code
B, we likely should apply it to Time Code A.
Best regards,
-Erik
[attachment "301x0b4e1-ProposedPinkSheet.docx" deleted by Gian Paolo
Calzolari/esoc/ESA] _______________________________________________
CESG mailing list
CESG at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg
This message and any attachments are intended for the use of the addressee
or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in
whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete
it from your system.
Emails can be altered and their integrity cannot be guaranteed by the
sender.
Please consider the environment before printing this email.
_______________________________________________
CESG mailing list
CESG at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg
_______________________________________________
CESG mailing list
CESG at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg
This message and any attachments are intended for the use of the addressee
or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in
whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete
it from your system.
Emails can be altered and their integrity cannot be guaranteed by the
sender.
Please consider the environment before printing this email.
This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.
Please consider the environment before printing this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20160805/b6aab028/attachment.html>
More information about the CESG
mailing list