Formatting of Time data fails #190
Assignees
Comments
MJJoyce
added a commit
that referenced
this issue
Jan 21, 2021
Update the handling of Field format calls to fix issues encountered with formatting time data and to handle the new diffed data changes. Format calls are now always run over the raw data of a field instead the "human readable" data when dealing with complex types or when the value of the field is not a "number". This could result from enumerated values on non-complex field. Manipulations can then be performed as necessary on the data prior to the format call if the data type requires it. For example, in the case of a Time object we decode the raw value into a Date object prior to formatting it so the sprintf library handles it properly. The dtype definitions for Time32 and Time64 have been updated so they can be used to decode Date objects from raw values. Note, there's no clean up done here of the other code in dtype that is effectively dead given the changes to the front / backend transmission formats. That needs handled in a follow on ticket. Note, there is the possibility for semi-strange situations to occur with packet caching and the current format handling. For example, consider a command field that is not labelled as raw with values that are undefined opcodes. The "human readable" packet diff will mark this field as "Unidentified Cmd" any time the opcode doesn't decode properly. As such, this field could be incorrectly cached and ignored if the raw value changed but the "human readable" value didn't since the cache check occurs on the initial pulled value (which relies on raw = true / false). Effectively, this means that users may need to be more explicit with marking fields as raw=true. Similarly, formatting on a given raw / not value isn't always consistent since we need to support time value formatting. Unfortunately there isn't a great way to handle this without significantly reducing functionality and the caveats (e.g., you can't dump a time field to hex) aren't likely to cause too much pain and suffering.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is related to #189 (and will likely be resolved as part of it) but formatting time datatype values is causing issues in the front end given the changes made to telemetry value deltas between the front / backends
The text was updated successfully, but these errors were encountered: