$)C<font size=2 face="Arial">Peter,</font>
<br>
<br><font size=2 face="Arial">I am trying to help to make the specs clearer.
I try below to put the point I raised in my email into a concrete proposal
for changing clause c (wording can certainly be improved), which in my
opinion is unambiguous (changes in red):</font>
<br>
<br><font size=2 face="Arial">===start proposal====</font>
<br><font size=2 face="Arial">Calendar or time subsets may contain all
the defined subfields, or may be abbreviated</font>
<br><font size=2 face="Arial">to the span of interest by deleting the unneeded
subfields</font><font size=2 color=red face="Arial"><strike>, either on
the left or on the</strike></font>
<br><font size=2 color=red face="Arial"><strike>right</strike></font><font size=2 face="Arial">.
However, when </font><font size=2 color=red face="Arial">'calendar'</font><font size=2 face="Arial">
subfields are deleted</font><font size=2 color=red face="Arial"><strike>
on the LEFT</strike></font><font size=2 face="Arial">, all separators that
had</font>
<br><font size=2 face="Arial">delimited the deleted subfields must be retained
(except for the !.T!/ which, by rule b,</font>
<br><font size=2 face="Arial">is dropped if the subset is used alone.)
When </font><font size=2 color=red face="Arial">'time' </font><font size=2 face="Arial">subfields
are deleted</font><font size=2 color=red face="Arial"><strike> on the RIGHT</strike></font><font size=2 face="Arial">,
the</font>
<br><font size=2 face="Arial">separators that had delimited the deleted
subfields are dropped.</font>
<br>
<br><font size=2 color=red face="Arial">Allowed subsetting of 'calendar'
subset are:</font>
<br><font size=2 color=red face="Arial">YYYY-DDD</font>
<br><font size=2 color=red face="Arial">-DDD</font>
<br>
<br><font size=2 color=red face="Arial">Allowed subsetting of 'time' subset
are:</font>
<br><font size=2 color=red face="Arial">hh:mm:ss.d!fd</font>
<br><font size=2 color=red face="Arial">hh:mm:ss</font>
<br><font size=2 color=red face="Arial">hh:mm</font>
<br><font size=2 color=red face="Arial">hh</font>
<br>
<br><font size=2 color=red face="Arial">Any allowed 'calendar' subset can
be joined to an allowed 'time' subset by means of the 'T' separator.</font>
<br>
<br><font size=2 color=red face="Arial">EXAMPLES:</font>
<br><font size=2 color=red face="sans-serif">YYYY-DDDThh:mm:ss</font>
<br><font size=2 color=red face="sans-serif">-DDDThh:mm</font>
<br><font size=2 color=red face="sans-serif">hh:mm:ss.d!fdZ </font>
<br><font size=2 color=red face="sans-serif">YYYY-DDD</font>
<br><font size=2 face="Arial">===end proposal====</font>
<br>
<br><font size=2 face="Arial">I also raised a point on the fact that the
separator 'Z' is optional, which went unanswered.</font>
<br>
<br><font size=2 face="Arial">Ciao</font>
<br>
<br><font size=2 face="Arial">__Mario</font>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">"Shames, Peter
M (312B)" <peter.m.shames@jpl.nasa.gov></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"Mario.Merri@esa.int"
<Mario.Merri@esa.int></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">"Gian.Paolo.Calzolari@esa.int"
<Gian.Paolo.Calzolari@esa.int>, "cesg@mailman.ccsds.org"
<cesg@mailman.ccsds.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">07/08/2016 21:18</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [CESG] CCSDS
301.0-B-4 propsed pink sheet (Time Code B) / Backward compatibility?</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=2 face="Calibri">In English this is what we call !0a tempest
in a teapot!1. This is all in one spec, in three clauses, one of
which has six sub-clauses. Various of us seem to have:</font>
<br><font size=2 face="Calibri">a) Not read all three
clauses</font>
<br><font size=2 face="Calibri">b) Only quoted parts
of one sub-clause, not even the whole of it</font>
<br><font size=2 face="Calibri">c) And this leads
to confusion !&</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">As with all CCSDS specs you do need to
read, understand, and comply with all normative parts of the spec. At
least here the ASCII Segmented Time Code is stated in 2.5 pages of one
rather modest spec and does not require a stack of three dense specs to
get to an understanding of what is required. And it is a spec that
has been around and in successful use since 1987. It just cannot
be a huge problem or source of confusion or it would have surfaced years
ago.</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">My concrete suggestion for !0fixing!1 this
was to add a few non-normative examples so that the meaning of the spec
is made even more clear. I provided what I thought was a reasonable
set of example that touch upon the major inflection points where valid
subsets can be created.</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">If anyone has an alternative concrete suggestion,
please offer it up so we can all return to more substantive issues.</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">Thanks, Peter</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri"> </font>
<br><font size=3 face="Calibri"><b>From: </b>Mario Merri <Mario.Merri@esa.int><b><br>
Date: </b>Saturday, August 6, 2016 at 11:52 PM<b><br>
To: </b>Peter Shames <peter.m.shames@jpl.nasa.gov><b><br>
Cc: </b>Gian Paolo Calzolari <Gian.Paolo.Calzolari@esa.int>, CCSDS
Engineering Steering Group - CESG Exec <cesg@mailman.ccsds.org><b><br>
Subject: </b>Re: [CESG] CCSDS 301.0-B-4 propsed pink sheet (Time Code B)
/ Backward compatibility?</font>
<br><font size=3 face="Times New Roman"> </font>
<br><font size=3 face="Times New Roman">It is so clear that we have been
discussing a week ...<br>
<br>
__Mario</font>
<br><font size=3 face="Times New Roman"><br>
On 6 Aug 2016, at 02:17, Shames, Peter M (312B) <</font><a href=mailto:peter.m.shames@jpl.nasa.gov><font size=3 color=blue face="Times New Roman"><u>peter.m.shames@jpl.nasa.gov</u></font></a><font size=3 face="Times New Roman">>
wrote:</font>
<br><font size=2 face="Calibri">I think the standard is quite clear enough
as it is if you read all the clauses, just like most of our specs. However,
I would support the addition of a non-normative corrigendum that provides
some examples. I do not think that that can be an exhaustive set
of examples because in spite of there being clear rules there are too many
possible combinations. I only showed a subset of the possible ones.</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">Regards, Peter</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri"> </font>
<br><font size=3 face="Calibri"><b>From: </b>Gian Paolo Calzolari <</font><a href=mailto:Gian.Paolo.Calzolari@esa.int><font size=3 color=blue face="Calibri"><u>Gian.Paolo.Calzolari@esa.int</u></font></a><font size=3 face="Calibri">><b><br>
Date: </b>Friday, August 5, 2016 at 3:08 AM<b><br>
To: </b>Mario Merri <</font><a href=mailto:Mario.Merri@esa.int><font size=3 color=blue face="Calibri"><u>Mario.Merri@esa.int</u></font></a><font size=3 face="Calibri">><b><br>
Cc: </b>Peter Shames <</font><a href=mailto:peter.m.shames@jpl.nasa.gov><font size=3 color=blue face="Calibri"><u>peter.m.shames@jpl.nasa.gov</u></font></a><font size=3 face="Calibri">>,
CCSDS Engineering Steering Group - CESG Exec <</font><a href=mailto:cesg@mailman.ccsds.org><font size=3 color=blue face="Calibri"><u>cesg@mailman.ccsds.org</u></font></a><font size=3 face="Calibri">><b><br>
Subject: </b>Re: [CESG] CCSDS 301.0-B-4 propsed pink sheet (Time Code B)
/ Backward compatibility?</font>
<br><font size=3 face="Times New Roman"> </font>
<br><font size=3 face="Times New Roman">Mario, you are basically repeating
my proposal; i.e. working on section 3.5.1.3 instead of adding the
optional field in section 3.5.1.2. :-)</font>
<br><font size=3 face="Times New Roman"><br>
<br>
</font>
<br><font size=3 face="Times New Roman">If we can do that just adding a
NOTE we might go for an editorial corrigendum as the addition would be
non normative. </font>
<br><font size=3 face="Times New Roman"><br>
<br>
</font>
<br><font size=3 face="Times New Roman">I go back to rest now</font>
<br><font size=3 face="Times New Roman"><br>
<br>
</font>
<br><font size=3 face="Times New Roman">Gippo</font>
<br><font size=3 face="Times New Roman"> </font>
<br><font size=3 face="Times New Roman"><br>
<br>
Sent from my iPhone</font>
<br><font size=3 face="Times New Roman"><br>
On 05 Aug 2016, at 09:45, </font><a href=mailto:Mario.Merri@esa.int><font size=3 color=blue face="Times New Roman"><u>Mario.Merri@esa.int</u></font></a><font size=3 face="Times New Roman">
wrote:</font>
<br><font size=2 face="Arial">Peter,</font><font size=3 face="Times New Roman">
<br>
</font><font size=2 face="Arial"><br>
my proposal would be:</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="Arial"><br>
1. No change is needed to accommodate Erik's request as this is already
foreseen by the standard</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
2. Improve the text in the standard to make the rules for subsetting clearer.</font><font size=3 face="Times New Roman">
<br>
</font><font size=2 face="Arial"><br>
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.</font><font size=3 face="Times New Roman">
<br>
</font><font size=2 face="Arial"><br>
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?</font><font size=3 face="Times New Roman">
<br>
</font><font size=2 face="Arial"><br>
Regards,</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="Arial"><br>
__Mario</font><font size=3 face="Times New Roman"> <br>
<br>
<br>
<br>
</font><font size=1 color=#5f5f5f><br>
From: </font><font size=1>"Shames, Peter
M (312B)" <</font><a href=mailto:peter.m.shames@jpl.nasa.gov><font size=1 color=blue><u>peter.m.shames@jpl.nasa.gov</u></font></a><font size=1>></font><font size=3 face="Times New Roman">
</font><font size=1 color=#5f5f5f><br>
To: </font><font size=1>"</font><a href=mailto:Mario.Merri@esa.int><font size=1 color=blue><u>Mario.Merri@esa.int</u></font></a><font size=1>"
<</font><a href=mailto:Mario.Merri@esa.int><font size=1 color=blue><u>Mario.Merri@esa.int</u></font></a><font size=1>>,
"Barkley, Erik J (3970)" <</font><a href=mailto:erik.j.barkley@jpl.nasa.gov><font size=1 color=blue><u>erik.j.barkley@jpl.nasa.gov</u></font></a><font size=1>></font><font size=3 face="Times New Roman">
</font><font size=1 color=#5f5f5f><br>
Cc: </font><font size=1>"</font><a href=mailto:cesg@mailman.ccsds.org><font size=1 color=blue><u>cesg@mailman.ccsds.org</u></font></a><font size=1>"
<</font><a href=mailto:cesg@mailman.ccsds.org><font size=1 color=blue><u>cesg@mailman.ccsds.org</u></font></a><font size=1>></font><font size=3 face="Times New Roman">
</font><font size=1 color=#5f5f5f><br>
Date: </font><font size=1>04/08/2016 23:42</font><font size=3 face="Times New Roman">
</font><font size=1 color=#5f5f5f><br>
Subject: </font><font size=1>Re: [CESG] CCSDS
301.0-B-4 propsed pink sheet (Time Code B) / Backward compatibility?</font><font size=3 face="Times New Roman">
</font>
<div align=center>
<hr noshade></div>
<br><font size=3 face="Times New Roman"><br>
<br>
</font><font size=2 face="Calibri"><br>
Hi Mario,</font><font size=3 face="Times New Roman"> </font><font size=2 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=2 face="Calibri"><br>
I!/m not clear what you are proposing. In one paragraph you say that
the standard is !0ok!1. 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?</font><font size=3 face="Times New Roman">
</font><font size=2 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=2 face="Calibri"><br>
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:</font><font size=3 face="Times New Roman">
</font><font size=2 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=4 face="Times New Roman"><br>
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. </font><font size=3 face="MS Mincho">?</font><font size=3 face="Times New Roman">
</font><font size=2 face="Calibri"><br>
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 !0calendarTtime!1 format would have to be judged non-compliant
with the spec.</font><font size=3 face="Times New Roman"> </font><font size=2 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=2 face="Calibri"><br>
According to the rules any of the following constructs should be acceptable:</font><font size=3 face="Times New Roman">
</font><font size=2 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=4 face="Times New Roman"><br>
YYYY-DDDThh:mm:ss.d</font><font size=4 face="Calibri">!f</font><font size=4 face="Times New Roman">dZ
<br>
YYYY-DDDThh:mm:ss.d</font><font size=4 face="Calibri">!f</font><font size=4 face="Times New Roman">d
<br>
-DDDThh:mm:ss <br>
-DDDThh:mm</font><font size=3 face="Times New Roman"> </font><font size=4 face="Times New Roman"><br>
hh:mm:ss.d</font><font size=4 face="Calibri">!f</font><font size=4 face="Times New Roman">dZ
<br>
YYYY-DDD</font><font size=3 face="Times New Roman"> </font><font size=2 face="Calibri"><br>
Perhaps a non-normative set of examples like this would have helped?</font><font size=3 face="Times New Roman">
</font><font size=2 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=2 face="Calibri"><br>
Thanks, Peter</font><font size=3 face="Times New Roman"> </font><font size=2 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=2 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=3 face="Calibri"><b><br>
From: </b>CESG <</font><a href="mailto:cesg-bounces@mailman.ccsds.org"><font size=3 color=blue face="Calibri"><u>cesg-bounces@mailman.ccsds.org</u></font></a><font size=3 face="Calibri">>
on behalf of Mario Merri <</font><a href=mailto:Mario.Merri@esa.int><font size=3 color=blue face="Calibri"><u>Mario.Merri@esa.int</u></font></a><font size=3 face="Calibri">><b><br>
Date: </b>Thursday, August 4, 2016 at 1:52 AM<b><br>
To: </b>Erik Barkley <</font><a href=mailto:erik.j.barkley@jpl.nasa.gov><font size=3 color=blue face="Calibri"><u>erik.j.barkley@jpl.nasa.gov</u></font></a><font size=3 face="Calibri">><b><br>
Cc: </b>CCSDS Engineering Steering Group - CESG Exec <</font><a href=mailto:cesg@mailman.ccsds.org><font size=3 color=blue face="Calibri"><u>cesg@mailman.ccsds.org</u></font></a><font size=3 face="Calibri">><b><br>
Subject: </b>Re: [CESG] CCSDS 301.0-B-4 propsed pink sheet (Time Code B)
/ Backward compatibility?</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="Arial"><br>
Hi Erik,</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
<br>
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:</font><font size=3 face="Times New Roman"> </font>
<ul>
<li><font size=2 face="Arial">[...] time subsets [...] may be abbreviated
to the span of interest by deleting the unneeded subfields, either on the
left or on the right. </font><font size=2 color=blue face="Arial">This
implies that one can delete the "d!fd" subfield</font><font size=3 face="Times New Roman">
</font>
<li><font size=2 face="Arial">When subfields are deleted on the RIGHT,
the separators that had delimited the deleted subfields are dropped. </font><font size=2 color=blue face="Arial">This
implies that one can delete the decimal dot</font></ul><font size=3 face="Symbol">!$</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
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.</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
<br>
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.</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
<br>
Regards,</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
<br>
__Mario</font><font size=3 face="Times New Roman"> <br>
<br>
</font><font size=1 color=#5f5f5f><br>
<br>
From: </font><font size=1>"Shames, Peter
M (312B)" <</font><a href=mailto:peter.m.shames@jpl.nasa.gov><font size=1 color=blue><u>peter.m.shames@jpl.nasa.gov</u></font></a><font size=1>></font><font size=3 face="Times New Roman">
</font><font size=1 color=#5f5f5f><br>
To: </font><font size=1>"Barkley, Erik
J (3970)" <</font><a href=mailto:erik.j.barkley@jpl.nasa.gov><font size=1 color=blue><u>erik.j.barkley@jpl.nasa.gov</u></font></a><font size=1>></font><font size=3 face="Times New Roman">
</font><font size=1 color=#5f5f5f><br>
Cc: </font><font size=1>"CESG -- CCSDS-Engineering
Steering Group\(</font><a href=mailto:cesg@mailman.ccsds.org><font size=1 color=blue><u>cesg@mailman.ccsds.org</u></font></a><font size=1>\)\(</font><a href=mailto:cesg@mailman.ccsds.org><font size=1 color=blue><u>cesg@mailman.ccsds.org</u></font></a><font size=1>\)"
<</font><a href=mailto:cesg@mailman.ccsds.org><font size=1 color=blue><u>cesg@mailman.ccsds.org</u></font></a><font size=1>></font><font size=3 face="Times New Roman">
</font><font size=1 color=#5f5f5f><br>
Date: </font><font size=1>04/08/2016 05:04</font><font size=3 face="Times New Roman">
</font><font size=1 color=#5f5f5f><br>
Subject: </font><font size=1>Re: [CESG] CCSDS
301.0-B-4 propsed pink sheet (Time Code B) / Backward compatibility?</font><font size=3 face="Times New Roman">
</font><font size=1 color=#5f5f5f><br>
Sent by: </font><font size=1>"CESG"
<</font><a href="mailto:cesg-bounces@mailman.ccsds.org"><font size=1 color=blue><u>cesg-bounces@mailman.ccsds.org</u></font></a><font size=1>></font><font size=3 face="Times New Roman">
</font>
<div align=center>
<hr noshade></div>
<br><font size=3 face="Times New Roman"><br>
<br>
<br>
<br>
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. <br>
<br>
Peter <br>
<br>
Sent from Peter's iPhone 6 <br>
<br>
Everything should be made as simple as possible, <br>
but not simpler. <br>
<br>
~Albert Einstein <br>
<br>
On Aug 3, 2016, at 6:34 PM, Barkley, Erik J (3970) <</font><a href=mailto:erik.j.barkley@jpl.nasa.gov><font size=3 color=blue face="Times New Roman"><u>erik.j.barkley@jpl.nasa.gov</u></font></a><font size=3 face="Times New Roman">>
wrote:</font><font size=2 color=#004080 face="Calibri"><br>
<br>
Gippo,</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 color=#004080 face="Calibri"><br>
I too noted that it might be possible to interpret 3.5.1.3 as already allowing
removal of the decimal fraction/sub-second. </font><font size=3 face="Times New Roman"><br>
</font><font size=2 color=#004080 face="Calibri"><br>
CESG members,</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 color=#004080 face="Calibri"><br>
What is your taking/reading on this? Does this already allow fractional
seconds to be optional? If not, why not? </font><font size=3 face="Times New Roman"><br>
</font><font size=2 color=#004080 face="Calibri"><br>
Best regards,</font><font size=3 face="Times New Roman"> </font><font size=2 color=#004080 face="Calibri"><br>
-Erik</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="Calibri"><b><br>
From:</b> </font><a href=mailto:Gian.Paolo.Calzolari@esa.int><font size=2 color=blue face="Calibri"><u>Gian.Paolo.Calzolari@esa.int</u></font></a><font size=2 face="Calibri">
[</font><a href=mailto:Gian.Paolo.Calzolari@esa.int><font size=2 color=blue face="Calibri"><u>mailto:Gian.Paolo.Calzolari@esa.int</u></font></a><font size=2 face="Calibri">]
<b><br>
Sent:</b> Monday, July 25, 2016 2:26 AM<b><br>
To:</b> Barkley, Erik J (3970) <</font><a href=mailto:erik.j.barkley@jpl.nasa.gov><font size=2 color=blue face="Calibri"><u>erik.j.barkley@jpl.nasa.gov</u></font></a><font size=2 face="Calibri">><b><br>
Cc:</b> CESG -- CCSDS-Engineering Steering Group (</font><a href=mailto:cesg@mailman.ccsds.org><font size=2 color=blue face="Calibri"><u>cesg@mailman.ccsds.org</u></font></a><font size=2 face="Calibri">)
(</font><a href=mailto:cesg@mailman.ccsds.org><font size=2 color=blue face="Calibri"><u>cesg@mailman.ccsds.org</u></font></a><font size=2 face="Calibri">)
<</font><a href=mailto:cesg@mailman.ccsds.org><font size=2 color=blue face="Calibri"><u>cesg@mailman.ccsds.org</u></font></a><font size=2 face="Calibri">><b><br>
Subject:</b> Re: [CESG] CCSDS 301.0-B-4 propsed pink sheet (Time Code B)
/ Backward compatibility?</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="Arial"><br>
Erik,</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
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 "</font><font size=3 face="Times New Roman">Decimal
fraction of second</font><font size=2 face="Arial">" and would most
likely crashes when that field is absent.</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
Conversely a constant setting to 0 when not used would be fully backward
compatible.</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
<br>
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.</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
In other words, the part of </font><font size=2 face="Calibri">3.5.1.3
clause (c)</font><font size=2 face="Arial"> 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?</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
<br>
My cent.......</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
<br>
Gian Paolo</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
<br>
PS It looks to me that the sentence "</font><font size=2 face="Times New Roman">the
need to accommodate the upcoming century rollover in only 11 years</font><font size=2 face="Arial">"
was somehow wrong in 2010 as it is now :o)</font><font size=3 face="Times New Roman">
<br>
<br>
</font><font size=1 color=#5f5f5f face="Arial"><br>
<br>
<br>
From: </font><font size=1 face="Arial">"Barkley,
Erik J (3970)" <</font><a href=mailto:erik.j.barkley@jpl.nasa.gov><font size=1 color=blue face="Arial"><u>erik.j.barkley@jpl.nasa.gov</u></font></a><font size=1 face="Arial">></font><font size=3 face="Times New Roman">
</font><font size=1 color=#5f5f5f face="Arial"><br>
To: </font><font size=1 face="Arial">"CESG
-- CCSDS-Engineering Steering Group (</font><a href=mailto:cesg@mailman.ccsds.org><font size=1 color=blue face="Arial"><u>cesg@mailman.ccsds.org</u></font></a><font size=1 face="Arial">)
(</font><a href=mailto:cesg@mailman.ccsds.org><font size=1 color=blue face="Arial"><u>cesg@mailman.ccsds.org</u></font></a><font size=1 face="Arial">)"
<</font><a href=mailto:cesg@mailman.ccsds.org><font size=1 color=blue face="Arial"><u>cesg@mailman.ccsds.org</u></font></a><font size=1 face="Arial">></font><font size=3 face="Times New Roman">
</font><font size=1 color=#5f5f5f face="Arial"><br>
Date: </font><font size=1 face="Arial">22/07/2016
01:44</font><font size=3 face="Times New Roman"> </font><font size=1 color=#5f5f5f face="Arial"><br>
Subject: </font><font size=1 face="Arial">[CESG]
CCSDS 301.0-B-4 propsed pink sheet (Time Code B)</font><font size=3 face="Times New Roman">
</font><font size=1 color=#5f5f5f face="Arial"><br>
Sent by: </font><font size=1 face="Arial">"CESG"
<</font><a href="mailto:cesg-bounces@mailman.ccsds.org"><font size=1 color=blue face="Arial"><u>cesg-bounces@mailman.ccsds.org</u></font></a><font size=1 face="Arial">></font><font size=3 face="Times New Roman">
</font>
<div align=center>
<hr noshade></div>
<br><font size=3 face="Times New Roman"><br>
<br>
</font><font size=2 face="Calibri"><br>
<br>
<br>
CESG Colleagues,</font><font size=3 face="Times New Roman"> </font><font size=2 face="Calibri"><br>
<br>
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 !0(optional)!1 which is in keeping with the method by
which optional is designated for the !0Z!1 character in the recommendation.
I believe the !0.!1 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. </font><font size=3 face="Times New Roman">
</font><font size=2 face="Calibri"><br>
<br>
Best regards,</font><font size=3 face="Times New Roman"> </font><font size=2 face="Calibri"><br>
-Erik</font><font size=3 face="Times New Roman"> </font><font size=2 face="Calibri"><br>
<br>
[attachment "301x0b4e1-ProposedPinkSheet.docx" deleted by Gian
Paolo Calzolari/esoc/ESA] </font><font size=2 face="Courier New">_______________________________________________<br>
CESG mailing list</font><font size=3 color=blue face="Times New Roman"><u><br>
</u></font><a href=mailto:CESG@mailman.ccsds.org><font size=2 color=blue face="Courier New"><u>CESG@mailman.ccsds.org</u></font></a><font size=3 color=blue face="Times New Roman"><u><br>
</u></font><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg"><font size=2 color=blue face="Courier New"><u>https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg</u></font></a><font size=2 face="Courier New"><br>
<br>
This message and any attachments are intended for the use of the addressee
or addressees only.</font><font size=3 face="Times New Roman"> </font><font size=2 face="Courier New"><br>
The unauthorised disclosure, use, dissemination or copying (either in whole
or in part) of its</font><font size=3 face="Times New Roman"> </font><font size=2 face="Courier New"><br>
content is not permitted.</font><font size=3 face="Times New Roman"> </font><font size=2 face="Courier New"><br>
If you received this message in error, please notify the sender and delete
it from your system.</font><font size=3 face="Times New Roman"> </font><font size=2 face="Courier New"><br>
Emails can be altered and their integrity cannot be guaranteed by the sender.</font><font size=3 face="Times New Roman">
<br>
</font><font size=2 face="Courier New"><br>
Please consider the environment before printing this email.</font><font size=3 face="Times New Roman">
<br>
_______________________________________________<br>
CESG mailing list</font><font size=3 color=blue face="Times New Roman"><u><br>
</u></font><a href=mailto:CESG@mailman.ccsds.org><font size=3 color=blue face="Times New Roman"><u>CESG@mailman.ccsds.org</u></font></a><font size=3 color=blue face="Times New Roman"><u><br>
</u></font><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg"><font size=3 color=blue face="Times New Roman"><u>https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg</u></font></a><font size=2 face="Courier New">_______________________________________________<br>
CESG mailing list</font><font size=2 color=blue face="Courier New"><u><br>
</u></font><a href=mailto:CESG@mailman.ccsds.org><font size=2 color=blue face="Courier New"><u>CESG@mailman.ccsds.org</u></font></a><font size=3 color=blue face="Times New Roman"><u><br>
</u></font><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg"><font size=2 color=blue face="Courier New"><u>https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg</u></font></a><font size=3 face="Times New Roman"><br>
</font><font size=2 face="Courier New"><br>
This message and any attachments are intended for the use of the addressee
or addressees only.</font><font size=3 face="Times New Roman"> </font><font size=2 face="Courier New"><br>
The unauthorised disclosure, use, dissemination or copying (either in whole
or in part) of its</font><font size=3 face="Times New Roman"> </font><font size=2 face="Courier New"><br>
content is not permitted.</font><font size=3 face="Times New Roman"> </font><font size=2 face="Courier New"><br>
If you received this message in error, please notify the sender and delete
it from your system.</font><font size=3 face="Times New Roman"> </font><font size=2 face="Courier New"><br>
Emails can be altered and their integrity cannot be guaranteed by the sender.</font><font size=3 face="Times New Roman">
</font><font size=2 face="Courier New"><br>
</font><font size=3 face="Times New Roman"> </font><font size=2 face="Courier New"><br>
Please consider the environment before printing this email.</font><font size=3 face="Times New Roman">
</font>
<br><font size=2 face="Courier New">This message and any attachments are
intended for the use of the addressee or addressees only.</font>
<br><font size=2 face="Courier New">The unauthorised disclosure, use, dissemination
or copying (either in whole or in part) of its</font>
<br><font size=2 face="Courier New">content is not permitted.</font>
<br><font size=2 face="Courier New">If you received this message in error,
please notify the sender and delete it from your system.</font>
<br><font size=2 face="Courier New">Emails can be altered and their integrity
cannot be guaranteed by the sender.</font>
<br><font size=2 face="Courier New"> </font>
<br><font size=2 face="Courier New">Please consider the environment before
printing this email.</font>
<br><font size=2 face="Courier New">This message and any attachments are
intended for the use of the addressee or addressees only.</font>
<br><font size=2 face="Courier New">The unauthorised disclosure, use, dissemination
or copying (either in whole or in part) of its</font>
<br><font size=2 face="Courier New">content is not permitted.</font>
<br><font size=2 face="Courier New">If you received this message in error,
please notify the sender and delete it from your system.</font>
<br><font size=2 face="Courier New">Emails can be altered and their integrity
cannot be guaranteed by the sender.</font>
<br><font size=2 face="Courier New"> </font>
<br><font size=2 face="Courier New">Please consider the environment before
printing this email.</font>
<br><font size=2 face="Courier New">This message and any attachments are
intended for the use of the addressee or addressees only.</font>
<br><font size=2 face="Courier New">The unauthorised disclosure, use, dissemination
or copying (either in whole or in part) of its</font>
<br><font size=2 face="Courier New">content is not permitted.</font>
<br><font size=2 face="Courier New">If you received this message in error,
please notify the sender and delete it from your system.</font>
<br><font size=2 face="Courier New">Emails can be altered and their integrity
cannot be guaranteed by the sender.</font>
<br><font size=2 face="Courier New"> </font>
<br><font size=2 face="Courier New">Please consider the environment before
printing this email.</font>
<br>
<br><PRE>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.
</PRE>