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

rtp.ISODateTime marshal with RFC3339 layout #47

Open
jerome-laforge opened this issue Nov 29, 2023 · 14 comments
Open

rtp.ISODateTime marshal with RFC3339 layout #47

jerome-laforge opened this issue Nov 29, 2023 · 14 comments
Labels
enhancement New feature or request question Further information is requested

Comments

@jerome-laforge
Copy link

jerome-laforge commented Nov 29, 2023

Hello,
When I marshal rtp.ISODateTime type, I have something like 2006-01-02T15:04:05 .
But it seems that we need to export with RFC3339 layout.

Do you think that it is possible do to define somewhere the time format that we want to use for marshaling?

Thx in adv for you support.

@adamdecaf
Copy link
Member

Your XML specs require RFC3339? We found with TCH that they don't support RFC3339.

@jerome-laforge
Copy link
Author

Yes, all dates in the provided examples are in RFC3339Milli layout : 2006-01-02T15:04:05.000Z07:00

@adamdecaf
Copy link
Member

When we've gone through testing for RTP with TCH we found the sub-second precision and timezone format was not accepted. We had to format timestamps as ISO 8601 in order to be accepted.

@jerome-laforge
Copy link
Author

Ok, that makes sens, but I don't want to change the default timestamp format.
Is it possible for you that define a global public variable with default format as ISO8601?
With this variable, I will be able to define the format (RFC3339 or something else) in order to marshall/unmarshall the ISODateTime.

@jerome-laforge
Copy link
Author

For now, I just fork and add the global variable (jerome-laforge@ac6fa87).

It is enough for me for now at this stage.
I will be back later in order to known if he format in example are OK or not (need to manage it more properly with the upstream driver).

Is it suitable for you?

@adamdecaf
Copy link
Member

Sounds good. Are you using this for RTP or FedNow? We're planning a separate fednow20022 repo with generated code since the two protocols use different ISO 20022 messages.

I'm fine adding that variable if it's needed.

@adamdecaf adamdecaf added enhancement New feature or request question Further information is requested labels Nov 30, 2023
@jerome-laforge
Copy link
Author

@jerome-laforge
Copy link
Author

FYI, I regenerate the model/validate with specific xsd and modified template.

@jerome-laforge
Copy link
Author

I'm fine adding that variable if it's needed.

Thx a lot 🙏

@adamdecaf
Copy link
Member

adamdecaf commented Nov 30, 2023

Okay, I understand better now. I found some information to help understand how ISO 20022 is being used for BCEAO.

https://gfrid.org/wp-content/uploads/2023/08/Senegal-CoP-September-2023_ISO-20022_EN__final.pdf
https://www.bceao.int/sites/default/files/2023-07/BCEAO%20-%20Rapport%20sur%20les%20IMF%2C%20Moyens%20et%20Services%20de%20Paiement_2020-2021.pdf

ISO 20022 is a very large set of XML specifications and different usages (countries, businesses, etc) adopt different parts of it. I would recommend you fork rtp20022 and adapt the templates/generators to your needs for BCEAO. I'm not sure how far we can stretch this repository to support both RTP and BCEAO. I will help you fork and setup the repo for your needs.

Do you have more details on the exact ISO 20022 messages used and how they're to be formatted?

@jerome-laforge
Copy link
Author

jerome-laforge commented Nov 30, 2023

Currently, I have just some example & xsd.
Nothing official yet.
When, I have the official data, forward you all xsd.

For now, I 've just :

  • generate model/validate based on xsd
  • unmarshal(example) => model
  • then marshal(model) => data
  • compare data given by marshal with provided examples

@adamdecaf
Copy link
Member

Did you figure out if you needed more changes? Or if a fork of rtp20022 would be your solution?

@jerome-laforge
Copy link
Author

Thank again for your support 🙏
For now based on the provided examples, the fork works fine with the modifications on:

I would have preferred that those 2 modifications were merged in the upstream (with the default values that allow keep current behavior for TCH). If those 2 modifications have been merged then I will be able to remove replace github.com/moov-io/rtp20022 v0.9.4 => github.com/jerome-laforge/rtp20022 v0.0.0-20231208075226-8e7a6baf36f9 directive from our go.mod.

@adamdecaf
Copy link
Member

I'm not sure we want to maintain extensible support for ISO 20022 and all of its various implementations. TCH makes a lot of changes to the ISO 20022 spec which are not compatible with BCEAO. We will help you stay updated with the generated code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants