rfc: test converting issues

Author: birkenfeld

rfcs/RFC-902-describe-specifier.rst

@@ -0,0 +1,43 @@
+- Feature: Equipment ID in Describing Message
+- Status: Rejected
+- Submit Date: 2017-05-30
+- Authors: SECoP committee
+- Type: Issue
+- PR:
+- Version: 1.0
+
+Summary
+=======
+
+Could the equipment ID go into the "specifier" field of the "describing"
+message?
+
+
+Issue text
+==========
+
+The equipment ID is a SEC node property, and it is therefore redundant
+to put it as the second item of the describe message.
+
+However as the describe/describing message might be extended later, for
+example to get the description of single modules only, we should specify
+a fixed word for the second item of the describe message, for example the
+keyword "ALL" or "All".
+
+At the meeting in Berlin (2017-05-30) this was discussed, but it was not
+yet decided the the keyword should be exactly. Until a final decision,
+SECoP clients should ignore the second item.
+
+Opinions
+--------
+
+We should use key keyword ALL (Markus Zolliker).
+
+Decision
+--------
+
+The decision was taken to use a bare period as placeholder:
+
+.. code::
+
+    describing . {"modules": ...

rfcs/RFC-903-timestamps.rst

@@ -0,0 +1,68 @@
+- Feature: Timestamp Format
+- Status: Final
+- Submit Date: 2017-05-30
+- Authors: SECoP committee
+- Type: Issue
+- PR:
+- Version: 1.0
+
+Summary
+=======
+
+Which format should timestamps in value qualifiers take?
+
+
+Issue text
+==========
+
+Proposals for the timestamp format are:
+
+ISO time format
+---------------
+
+A date+time string in ISO format like "2017-06-21T13:30:01.123456+02:00"
+
+The fractional seconds are optional, but the timezone has to be given. Z is allowed instead of +00:00.
+
+Advantages:
+
+* human readable
+
+Disadvantages:
+
+* needs more conversion efforts, as the time is internally already stored as
+  numbers on mosts systems (supporting math operations)
+* although the ISO standard is clearly defined, there is a risk that time zones
+  and daylight saving time is not handled properly
+
+Fractional Unix Time
+--------------------
+
+Seconds since 1970-01-01T00:00:00+00:00, represented as a number. When converted
+to a IEEE double, a resolution of 1 usec can be kept for dates up to 2112.
+
+Advantages:
+
+* if a double is used as an internal representation, no conversion is
+  needed. using a double as an internal time representation has the advantage,
+  that math operations can be done for free.
+* relative times for systems with no synchronized clock can be represented
+  easily
+
+Disadvantages:
+
+* not human readable (or at least not easily: time differences in seconds are
+  still visible)
+
+Discussion
+----------
+
+1) Human readibility was judged less important than easy implementaion by the majority.
+
+2) Implementing relative times is also easier.
+
+Decision
+--------
+
+At the meeting in Berlin (2017-05-30) the attendes decided for "Fractional Unix Time".
+The resolution of the timestamp depends on the hardware, but must be at least one second.