Bug 55452 - UDM representation of accountActivationDate
UDM representation of accountActivationDate
Status: NEW
Product: UCS
Classification: Unclassified
Component: UMC - Users
UCS 5.0
Other Linux
: P5 normal (vote)
: ---
Assigned To: UMC maintainers
UMC maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2022-11-23 18:40 CET by Florian Best
Modified: 2022-11-23 18:41 CET (History)
0 users

See Also:
What kind of report is it?: Development Internal
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Florian Best univentionstaff 2022-11-23 18:40:37 CET
We got feedback from Michael about the UDM representation of users/user accountActivationDate:

"""
what was actually the motivation for using a dict for timestamps as a UDM property?

    "accountActivationDate": {
      "activation-timezone": "Europe/Berlin",
      "activation-time": null,
      "activation-date": null
    },

1. RFC 3339 defines a complete string representation that is readable by machines and humans:

https://www.rfc-editor.org/rfc/rfc3339

2. if you use names in the timezone, it is mandatory that the whole timezone stuff is available on UDM clients as well, e.g. to convert timezones.

3. python already has sufficiently good time/date parsers. If you really need correct timezone info of the past, e.g. summer/standard time mapping when displaying local time, you can use additional modules (e.g. pytz).

4. the above example is actually much too complex to represent a simple zero value.
"""