Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider Interface extension TimeProvider::from_now_with_u16/24_days() #4

Open
weberdaniel opened this issue Dec 7, 2023 · 2 comments

Comments

@weberdaniel
Copy link

weberdaniel commented Dec 7, 2023

Given the timeprovider example:

let timestamp_now = TimeProvider::from_now_with_u16_days().unwrap();

One could extend the interface of ::from_now_with_u16/24_days() with an optional argument to enable little vs big endianness. Doing this manually on the ouput bytes would be rather cumbersome.

@robamu
Copy link
Contributor

robamu commented Dec 8, 2023

Page 16 of the CCSDS standard mentions that all segments in the CDS timestamp are right adjusted binary counters. May I know why you need little endian for those individual fields? If you need to read them low level from C/C++ code, functions like ntohs should do the job as well.

@weberdaniel
Copy link
Author

weberdaniel commented Mar 5, 2024

You are right, endianness is not in the scope of the standard. TimeWriter/TimeReader trait for TimeProvider are good starting point for customization, but extending the interface with custom functions for each corner case will probably grow the interface too quickly, especially since time implementations can get large/complex and the standard allows to omit p-field which creates lot of ambiguity for the read case. Strategy pattern might be a way to let user customize output/input. Effort/Time invest here is probably the biggest showstopper.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants