[Bug]: Email shares store expiration in a different timezone and omit file_target

[hweihwang]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on GitHub or the Nextcloud Community Forum. I searched for sharebymail expiration timezone, ocMailShare file_target, share_type 4 expiration, and related variants.
• Nextcloud Server is up to date. This was checked against Nextcloud 33.0.3 and current master code.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

Email shares (share_type = 4, provider id ocMailShare) do not persist share metadata consistently with user shares and public link shares:

1. The expiration date is stored with a different timezone conversion behavior.
2. file_target is stored as NULL for newly created email shares.

For the expiration date, the OCS share API parses expireDate in the configured/user timezone and OC\Share20\Manager::validateExpirationDateLink() normalizes link/email share expiration to the end of the selected day (23:59:59) in that timezone. Public link shares then go through OC\Share20\DefaultShareProvider, which clones the expiration date and converts it to date_default_timezone_get() before writing it to the database.

Email shares go through OCA\ShareByMail\ShareByMailProvider::addShareToDB() instead. That method writes the original DateTimeInterface directly as expiration and does not set file_target. This creates different database values for the same selected expiration date compared with public link shares.

This is easiest to see on non-UTC timezones such as Asia/Tokyo.

Relevant code paths in current master:

• apps/files_sharing/lib/Controller/ShareAPIController.php: parseDate() creates the date in $this->dateTimeZone->getTimeZone().
• lib/private/Share20/Manager.php: validateExpirationDateLink() sets link/email expiration to 23:59:59 in the configured timezone.
• lib/private/Share20/DefaultShareProvider.php: normal providers clone expiration, convert it to date_default_timezone_get(), and persist file_target.
• apps/sharebymail/lib/ShareByMailProvider.php: addShareToDB() persists $expirationTime directly and does not write file_target.

Steps to reproduce

1. Use a Nextcloud instance with PHP/Nextcloud timezone set to a non-UTC timezone, for example Asia/Tokyo.
2. Enable files_sharing and sharebymail.
3. Create a folder, for example /Documents.
4. Create a public link share for /Documents with an expiration date, for example 2026-05-19.
5. Create an email share for the same /Documents folder with the same expiration date, for example to recipient@example.invalid.
6. Compare the generated rows in oc_share, especially share_type, expiration, and file_target.

Example query:

SELECT id, share_type, share_with, file_source, file_target, expiration
FROM oc_share
WHERE file_source = <fileid>
ORDER BY id;

Expected behavior

Email shares should persist the selected expiration date consistently with public link shares.

For a selected expiration date in a non-UTC timezone, share_type = 4 should resolve to the same effective end-of-day instant as share_type = 3.

Email shares should also persist file_target for the shared file/folder path, the same way the default share provider does for user and public link shares.

Nextcloud Server version

33

Operating system

Other

PHP engine version

PHP 8.2

Web server

Nginx

Database engine version

MariaDB

Is this bug present after an update or on a fresh install?

Fresh Nextcloud Server install

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

{
    "dbtype": "mysql",
    "version": "33.0.3.3",
    "default_timezone": "Asia/Tokyo"
}

List of activated Apps

- files_sharing
- sharebymail

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

No relevant server log entry is generated. The issue is visible in the persisted oc_share row.

Additional info

This appears related to the provider-specific create/update path for email shares rather than to a database engine issue.

ShareByMailProvider::addShareToDB() currently does not mirror the normalization used by DefaultShareProvider before writing expiration, and it does not write file_target at all.

PR #58128 changed share expiration to end-of-day (23:59:59). This report is not about that behavior change itself; it is about email shares not persisting the same effective expiration instant as public link shares after that normalization.