Difference in the expiration date response for shares and links #11232

jesmrec · 2025-04-11T07:58:23Z

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)

The text was updated successfully, but these errors were encountered:

2403905 · 2025-04-15T07:23:43Z

@jesmrec Could you clarify what quest you are executing? Here is an invite request for sharing via UI and I see that TZ is respected.

curl $'https://localhost:9200/graph/v1beta1/drives/faa02a4f-f325-4143-a97a-978a9d6654d5%24some-admin-user-id-0000-000000000000/items/faa02a4f-f325-4143-a97a-978a9d6654d5%24some-admin-user-id-0000-000000000000\u0021d173ceca-33cf-4f3d-a672-1f998a39e7ef/invite' \
  --data-raw '{"roles":["b1e2218d-eef8-4d4c-b82d-0f1a1b48f3b5"],"expirationDateTime":"2025-04-16T23:59:59.999+02:00","recipients":[{"objectId":"058bff95-6708-4fe5-91e4-9ea3d377588b","@libre.graph.recipient.type":"user"}]}' \
  --insecure

response:

{
    "value": [
        {
            "createdDateTime": "2025-04-15T09:13:33.434913+02:00",
            "expirationDateTime": "2025-04-16T23:59:59.999+02:00",
            "grantedToV2": {
                "user": {
                    "@libre.graph.userType": "Member",
                    "displayName": "Maurice Moss",
                    "id": "058bff95-6708-4fe5-91e4-9ea3d377588b"
                }
            },
            "id": "faa02a4f-f325-4143-a97a-978a9d6654d5:some-admin-user-id-0000-000000000000:5c9f83ff-4ef3-4e41-91e1-be8d9118330e",
            "invitation": {
                "invitedBy": {
                    "user": {
                        "@libre.graph.userType": "Member",
                        "displayName": "Admin",
                        "id": "some-admin-user-id-0000-000000000000"
                    }
                }
            },
            "roles": [
                "b1e2218d-eef8-4d4c-b82d-0f1a1b48f3b5"
            ]
        }
    ]
}

2403905 · 2025-04-15T07:27:54Z

For the Public link, I can confirm, no TZ in a responce. It looks inconsistent.

jesmrec · 2025-04-15T08:16:42Z

        "createdDateTime": "2025-04-15T09:13:33.434913+02:00",
        "expirationDateTime": "2025-04-16T23:59:59.999+02:00",

09:13:33 vs 23:59:59

this is the issue. In "Share with users", both created and expiration have the same timestamp.

2403905 · 2025-04-15T09:55:08Z

09:13:33 vs 23:59:59

this is the issue. In "Share with users", both created and expiration have the same timestamp.

Sorry I didn't get it in your reply. Why the timestamps are the same?

jesmrec · 2025-04-15T10:29:08Z

@2403905 i will give the complete info with the requests, i hope it helps ;)

Link creation:

curl 
-H 'Host: xx.xx.xx.xx:9200' \
-H 'Content-Type: application/json' \
-H 'Accept: */*' \
-H 'Original-Request-ID: A32BBC5C-D26A-4F3B-9C34-1E7778E9C868' --compressed \
-H 'Connection: keep-alive' \
-H 'User-Agent: ownCloudApp/12.4.0 (App/296; iOS/18.4; iPhone)' \
-H 'Accept-Language: en' \
-H 'Authorization: Bearer...' \
-H 'X-Request-ID: A32BBC5C-D26A-4F3B-9C34-1E7778E9C868' \
-X POST 'https://xx.xx.xx.xx:9200/graph/v1beta1/drives/7929d021-626d-4cb8-b634-3eec3c0e1b1d$2494c3cf-79ca-4f82-ae15-5b3c75ab5787/items/7929d021-626d-4cb8-b634-3eec3c0e1b1d$2494c3cf-79ca-4f82-ae15-5b3c75ab5787!422a3f16-1ace-485f-8b2d-90fa05e41582/createLink' \
-d '{"password":"...","displayName":"","type":"view","expirationDateTime":"2025-05-12T10:15:00.000Z"}'

Response payload:

{
    "createdDateTime": "2025-04-15T10:15:51.651071123Z",
    "expirationDateTime": "2025-05-12T23:59:59Z",
    "hasPassword": true,
    "id": "aMgiaRMHtYCHpRn",
    "link": {
        "@libre.graph.displayName": "",
        "@libre.graph.quickLink": false,
        "preventsDownload": false,
        "type": "view",
        "webUrl": "https://xx.xx.xx.xx:9200/s/QiQBbRAgQYxikrV"
    }
}

Creation in response (at the right of the T): 10:15:51.651071123
Expiration in response (at the right of the T): 23:59:59Z

Different, why? ❌

On the other side, sharing with a user:

curl 
-H 'Host: xx.xx.xx.xx:9200' \
-H 'Content-Type: application/json' \
-H 'Accept: */*' \
-H 'Original-Request-ID: DE294308-60F1-49F0-90F0-A2AC91BD363D' --compressed \
-H 'Connection: keep-alive' \
-H 'User-Agent: ownCloudApp/12.4.0 (App/296; iOS/18.4; iPhone)' \
-H 'Accept-Language: en' \
-H 'Authorization: Bearer ...' \
-H 'X-Request-ID: DE294308-60F1-49F0-90F0-A2AC91BD363D' \
-X POST 'https://xx.xx.xx.xx:9200/graph/v1beta1/drives/7929d021-626d-4cb8-b634-3eec3c0e1b1d$2494c3cf-79ca-4f82-ae15-5b3c75ab5787/items/7929d021-626d-4cb8-b634-3eec3c0e1b1d$2494c3cf-79ca-4f82-ae15-5b3c75ab5787!422a3f16-1ace-485f-8b2d-90fa05e41582/invite' \
-d '{"recipients":[{"@libre.graph.recipient.type":"user","objectId":"6ce4f14c-2d3c-48c3-bef3-bca16d20ba86"}],"roles":["b1e2218d-eef8-4d4c-b82d-0f1a1b48f3b5"],"expirationDateTime":"2025-05-12T10:21:00.000Z"}'

and the response payload:

{
    "value": [
        {
            "createdDateTime": "2025-04-15T10:21:37.473413217Z",
            "expirationDateTime": "2025-05-12T10:21:00Z",
            "grantedToV2": {
                "user": {
                    "@libre.graph.userType": "Member",
                    "displayName": "user2",
                    "id": "6ce4f14c-2d3c-48c3-bef3-bca16d20ba86"
                }
            },
            "id": "7929d021-626d-4cb8-b634-3eec3c0e1b1d:2494c3cf-79ca-4f82-ae15-5b3c75ab5787:11f6048e-ad39-4409-9dac-e5e73c5ca029",
            "invitation": {
                "invitedBy": {
                    "user": {
                        "@libre.graph.userType": "Member",
                        "displayName": "Joeh Smith",
                        "id": "2494c3cf-79ca-4f82-ae15-5b3c75ab5787"
                    }
                }
            },
            "roles": [
                "b1e2218d-eef8-4d4c-b82d-0f1a1b48f3b5"
            ]
        }
    ]
}

Creation date in response (at the right of the T): 10:21:37.473413217Z
Expiration date in response (at the right of the T): 10:21:00Z

They are the same ✅

Summing up:

Links creation always returns 23:59:59. If we are in UTC (+2), it will always move the expiration to the next day, regardless the time it was created.
Shares creation returns the same date as creation (in the example above 10:21).

Let me know if something else could be useful.

2403905 · 2025-04-15T12:17:28Z

Links creation always returns 23:59:59. If we are in UTC (+2), it will always move the expiration to the next day, regardless the time it was created.

No, it doesn't. If the client sends the expiration time within the TZ the ocis respects the TZ. The response from ocis returns the expirationDateTime in UTC

req: "expirationDateTime":"2025-04-16T23:59:59.999+02:00"
resp: "expirationDateTime": "2025-04-16T21:59:59Z",

curl $'https://localhost:9200/graph/v1beta1/drives/faa02a4f-f325-4143-a97a-978a9d6654d5%24some-admin-user-id-0000-000000000000/items/faa02a4f-f325-4143-a97a-978a9d6654d5%24some-admin-user-id-0000-000000000000\u0021d173ceca-33cf-4f3d-a672-1f998a39e7ef/createLink' \
  --data-raw '{"type":"view","@libre.graph.quickLink":false,"password":"&Rj3W[7c{65D","expirationDateTime":"2025-04-16T23:59:59.999+02:00","displayName":"Unnamed link"}'

response:

{
    "createdDateTime": "2025-04-15T12:06:05.108349Z",
    "expirationDateTime": "2025-04-16T21:59:59Z",
    "hasPassword": true,
    "id": "KnPPmGiHadvXkoE",
    "link": {
        "@libre.graph.displayName": "Unnamed link",
        "@libre.graph.quickLink": false,
        "preventsDownload": false,
        "type": "view",
        "webUrl": "https://localhost:9200/s/esBCzXWHEvXhUQT"
    }
}

2403905 · 2025-04-15T12:25:48Z

I see two issues with the public link expirationDateTime

the expirationDateTime in a response always in UTC
The client can't set the arbitrary expirationDateTime. The server changes the expirationDateTime to the end of the day considering TZ.

jesmrec · 2025-04-15T12:39:04Z

The client can't set the arbitrary expirationDateTime. The server changes the expirationDateTime to the end of the day considering TZ.

but only in links and not in shares. Both should behave the same.

2403905 · 2025-04-16T09:41:38Z

@saw-jan Do you know why ocis sets the end of day for expirationDateTime only for the public link?

saw-jan · 2025-04-17T06:54:45Z

@saw-jan Do you know why ocis sets the end of day for expirationDateTime only for the public link?

TBH, I have no idea about this. Maybe it is by design or a bug in oCIS.

As far as I understood, @jesmrec's point is user share has 24-hour expiry duration whereas link share has end-of-day expiry duration
We should find out what is the expected behaviour. Maybe @kobergj can help here.

2403905 · 2025-04-17T11:17:05Z

In my opinion, the API should not restrict the client from setting any future expirationDateTime. All other staff like next 24-hour or end-of-day, it is UI sugar.

saw-jan · 2025-04-22T07:07:28Z

@jesmrec I see different behavior than what you have posted.

Link share

POST https://localhost:9200/graph/v1beta1/drives/{id}/items/{id}/createLink
# Req body
{
    "type": "view",
    "@libre.graph.quickLink": false,
    "password": "8B6>Z<ucW7='",
    "expirationDateTime": "2025-04-23T23:59:59.999+05:45", 👈
    "displayName": "Unnamed link"
}

# Response
{
    "createdDateTime": "2025-04-22T06:59:40.252970115Z", 👈
    "expirationDateTime": "2025-04-23T18:14:59Z", 👈
    ...
}

User share

POST https://localhost:9200/graph/v1beta1/drives/{id}/items/{id}/invite
# Req body
{
    "roles": [
        "b1e2218d-eef8-4d4c-b82d-0f1a1b48f3b5"
    ],
    "expirationDateTime": "2025-04-23T23:59:59.999+05:45", 👈
    "recipients": [
        {
            "objectId": "2a16bc38-f5d9-4c5e-b7f3-676a519f9699",
            "@libre.graph.recipient.type": "user"
        }
    ]
}

# Response
{
    "value": [
        {
            "createdDateTime": "2025-04-22T06:57:53.788517402Z", 👈
            "expirationDateTime": "2025-04-23T18:14:59.999Z", 👈
            ...
        }
    ]
}

The format for expiry date is different, but the value is the same.

jesmrec · 2025-04-24T06:49:46Z

"expirationDateTime": "2025-04-23T18:14:59Z",

This is because your TZ. If, for example, you are in Nepal and your server is in central Europe, that expirationDateTime would be "2025-04-23T23:59:59Z" instead.

The problem only affects "Link share". The "User share" is correct, as explained above. @saw-jan

saw-jan · 2025-04-24T08:56:50Z

So the problem is: 2025-04-23T18:14:59Z vs 2025-04-23T18:14:59.999Z
right?

jesmrec · 2025-04-24T09:38:44Z

The problem is: no matter at what time you create a link, it will be returned 23:59:59 at the server time zone.

saw-jan · 2025-04-24T09:43:02Z

Is it problem with the timezone? because I got 2025-04-23T18:14:59 for both user and link share with exception of Z and .999Z.
So, no 23.59.59

jesmrec · 2025-04-24T10:05:20Z

Where are your server and clients located? same location or time setup?

saw-jan · 2025-04-24T11:33:45Z

Where are your server and clients located? same location or time setup?

they are on same location (i.e: my machine)

jesmrec · 2025-04-24T11:53:32Z

You send in your POST for creating a link:

"expirationDateTime": "2025-04-23T23:59:59.999+05:45",

right?

what happens if you send

"expirationDateTime": "2025-04-23T13:12:23.999+05:45",

saw-jan · 2025-04-24T12:02:43Z

Ahh, now I get it.
I posted the request body from the web. So, the web uses 23:59:59.999+05:45. Let me try setting time other than 23:59

2403905 · 2025-04-30T15:18:05Z

@felix-schwarz Hi Felix. Could you validate the changes? #11239

saw-jan · 2025-05-05T07:27:12Z

I found some comments related to this:
#8071 (comment)

from https://matrix.to/#/!QxIasTYvslDCVqoPzC:matrix.org/$fBktWHnp3ed_mdEokzmlHXkoHReuO3F5MpLpMWrnLDk?via=matrix.org&via=openproject.org&via=matrix.datenschmutz.space

Niraj Acharya(Jankari Tech): when i create a share link for a file and set the expiration date to some thing like Friday, December 15, 2023 12:00:00 AM the experation date is set to Friday, December 15, 2023 11:59:59 PM. does the createLink endpoint set the expiration date to the last second of the day and not the given date?
https://owncloud.dev/libre-graph-api/#/drives.permissions/CreateLink

Michael Barz: Yes that is correct. The OCS was behaving exactly like that.

jesmrec · 2025-05-05T12:49:16Z

Then, could the problem be in the "share with users", that does not send the "23:59:59" so, the creation one, instead?

jesmrec added the Type:Bug label Apr 11, 2025

jesmrec mentioned this issue Apr 11, 2025

[feature/sharing-ng] Support for new ocis spaces/sharing capabilities owncloud/ios-app#1435

Merged

44 tasks

2403905 linked a pull request Apr 16, 2025 that will close this issue

Fix the expiration date response for links #11239

Open

9 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Difference in the expiration date response for shares and links #11232

Difference in the expiration date response for shares and links #11232

jesmrec commented Apr 11, 2025 •

edited

Loading

2403905 commented Apr 15, 2025

2403905 commented Apr 15, 2025 •

edited

Loading

jesmrec commented Apr 15, 2025

2403905 commented Apr 15, 2025

jesmrec commented Apr 15, 2025 •

edited

Loading

2403905 commented Apr 15, 2025

2403905 commented Apr 15, 2025

jesmrec commented Apr 15, 2025

2403905 commented Apr 16, 2025 •

edited

Loading

saw-jan commented Apr 17, 2025

2403905 commented Apr 17, 2025

saw-jan commented Apr 22, 2025

jesmrec commented Apr 24, 2025

saw-jan commented Apr 24, 2025

jesmrec commented Apr 24, 2025

saw-jan commented Apr 24, 2025

jesmrec commented Apr 24, 2025

saw-jan commented Apr 24, 2025

jesmrec commented Apr 24, 2025

saw-jan commented Apr 24, 2025

2403905 commented Apr 30, 2025

saw-jan commented May 5, 2025

jesmrec commented May 5, 2025

Difference in the expiration date response for shares and links #11232

Difference in the expiration date response for shares and links #11232

Comments

jesmrec commented Apr 11, 2025 • edited Loading

Describe the bug

Steps to reproduce

Actual behavior

Expected behavior

Setup

2403905 commented Apr 15, 2025

2403905 commented Apr 15, 2025 • edited Loading

jesmrec commented Apr 15, 2025

2403905 commented Apr 15, 2025

jesmrec commented Apr 15, 2025 • edited Loading

2403905 commented Apr 15, 2025

2403905 commented Apr 15, 2025

jesmrec commented Apr 15, 2025

2403905 commented Apr 16, 2025 • edited Loading

saw-jan commented Apr 17, 2025

2403905 commented Apr 17, 2025

saw-jan commented Apr 22, 2025

Link share

User share

jesmrec commented Apr 24, 2025

saw-jan commented Apr 24, 2025

jesmrec commented Apr 24, 2025

saw-jan commented Apr 24, 2025

jesmrec commented Apr 24, 2025

saw-jan commented Apr 24, 2025

jesmrec commented Apr 24, 2025

saw-jan commented Apr 24, 2025

2403905 commented Apr 30, 2025

saw-jan commented May 5, 2025

jesmrec commented May 5, 2025

jesmrec commented Apr 11, 2025 •

edited

Loading

2403905 commented Apr 15, 2025 •

edited

Loading

jesmrec commented Apr 15, 2025 •

edited

Loading

2403905 commented Apr 16, 2025 •

edited

Loading