-
Notifications
You must be signed in to change notification settings - Fork 24
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
Add UTC precision for SIMswap date. #43
Comments
We usually for these kind of parameters use descriptions like this for example: Timestamp of latest SIM swap performed, in ISO-8601 extended local date format. Time-offset from UTC may be used to match the local time. but besides being date-time we don't force it. How do you suggest to have it as explicit? With a pattern? |
@monamok Thanks. No I did no plan to change the attribute formatting. My proposal was just to update the description to make it explicit. |
Thank you @bigludo7. The example I added was more kind of recommendation without saying explicitly that it must be UTC, It's more focused on ISO-8601 standard. Do you think using UTC must be part of the guideline? I'm not sure if there are more APIs over CAMARA that use date-time parameters. P.D. I opened this issue #42 last week in order to improve and align the documentation with the guidlines. Once decided, we can include this point in a common PR for both issues. |
@monamok : I will propose a very small update in the design guideline document to indicate that datetime attribute has to use UTC (if nothing explicitly else). |
Thank you @bigludo7 |
Added UTC Precision (camaraproject#43) + Error Message (camaraproject#44 (comment))
Why it must be UTC? "ISO 8601" includes timezone as well, so the API client does not need to have any assumptions on its side. |
AP - take this item to commonalities |
Problem description
What is the time zone for the date time provided by the SIM swap get date?
Possible evolution
Indicate in the description that we use UTC (Coordinated Universal time)
I guess this in implicit right now but better to be explicit?
@monamok @DT-DawidWroblewski WDYT?
The text was updated successfully, but these errors were encountered: