-
Notifications
You must be signed in to change notification settings - Fork 14
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
Serialiser_Engine: Force invariant representation of number in serialisation #3134
Serialiser_Engine: Force invariant representation of number in serialisation #3134
Conversation
@BHoMBot check serialisation |
@FraserGreenroyd to confirm, the following actions are now queued:
There are 9 requests in the queue ahead of you. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have reviewed the code and the changes make sense, and I cannot think of any other places currently where we would need to do this within the core engine.
I think it's worth capturing a wiki page on this convention for future reference, but that can be done independently of deploying this fix for ZCT or other platforms requiring it.
@FraserGreenroyd to confirm, the following actions are now queued:
There are 11 requests in the queue ahead of you. |
The check |
The check |
The check |
@BHoMBot this is a DevOps instruction. I am requesting neutral checks on: versioning, unit-tests, ready-to-merge |
@FraserGreenroyd I have provided neutral checks to the checks requested. These checks will need to be run properly to obtain full results. |
Issues addressed by this PR
Closes #3130
Overall, the serialisation of numbers was already relying on Mongo to do things correctly but there was a few cases where we were doing a 'manual' conversion to/from strings.
I used
CultureInfo.InvariantCulture
instead ofen-GB
because it is more robust to changesIntegers don't need formatting constraints as they don't change across cultures. I also checked other types like
Timespan
andDateTime
and they don't need any modification as the first is invariant across cultures for default formatting and the second is represented as a long anyways.