You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
leo-da
changed the title
Enhance Navigator's lf-value-json encoding to fully support DAML primitives
Enhance Navigator's lf-value-json encoding to fully support DAML LF primitives
Jul 31, 2019
In most contexts, we expect LF values to have been pre-rounded, and don't do rounding again in order to avoid the risk of discarding data. That includes the Time.Timestamp LF Scala type underlying the LF Value ADT.
For the JSON format, we state:
Numbers must be within the bounds of Decimal, [–(10³⁸–1)÷10¹⁰, (10³⁸–1)÷10¹⁰]. Numbers outside those bounds will be rejected. Numbers inside the bounds will always be accepted, using banker's rounding to fit them within the precision supported by Decimal.
Hypothetically, we could read timezones in the timestamp format. Instead, we only permit Z, and moreover require that Z is specified.
The UTC timezone designator must be included. The rationale behind the inclusion of the timezone designator is minimizing the risk that users pass in local times.
The Optional rules provide a consistent core rule for nested optionals:
the innermost Optional (i.e. any optional without an optional directly therein) doesn't have a marker. null or absence (in the case of a surrounding [] for containing optional) means None.
[] is a valid Some None.
This is the ruleset for the Optional section, but some other encodings assume something incompatible. For example, [42] is never a valid Optional Int under this scheme, nor is [] a valid None.
Large
Decimal
values is one of the cases.See #2519
The text was updated successfully, but these errors were encountered: