Describe the bug

Creation of public link and share with expiration date, returns timestamps in a different way

Steps to reproduce

Using iOS client, i created a "link" and a "share with user" over the same item, correct POST requests with 200

Actual behavior

Link creation POST request returns:

    "createdDateTime": "2025-04-11T07:38:10.550603897Z",
    "expirationDateTime": "2025-05-12T23:59:59Z",

Created at 07:38:10 UTC, but expiration time at 23:59:59 UTC

Share creation POST request returns:

    "createdDateTime": "2025-04-11T07:37:22.529264403Z",
    "expirationDateTime": "2025-05-12T07:37:00Z",

Created at 07:37:22 UTC, and expiration time at 07:37:00 UTC (ignoring seconds, but this is OK, no problem)

Expected behavior

Both kind of shares with the same way: both 23:59:59, or both in the creation timestamp. I'd go for the second one, more precise.

OTOH, the fact of setting 23:59:59UTC in links is leading to a side-effect in clients. In the Europe Zone, UTC is +2 (summer time). That means, if i set as expiration date, f. ex, 12th May, server returns 12/05 23:59:59UTC, that goes to 13 May, that's not the date the user set within the same time zone.

As a question: would't be better to retrieve dates in the creation TZ? I mean, if i am in UTC+2, dates retrieved in UTC+2 not it UTC, regardless which format they are stored in backend.

Setup

oCIS 7.1.1
(ask me if you need more details)