Skip to content
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

[Bug]: Use system timezone in calculation of share times #42453

Closed
4 of 8 tasks
Fenn-CS opened this issue Dec 22, 2023 · 3 comments · Fixed by #42660
Closed
4 of 8 tasks

[Bug]: Use system timezone in calculation of share times #42453

Fenn-CS opened this issue Dec 22, 2023 · 3 comments · Fixed by #42660
Assignees

Comments

@Fenn-CS
Copy link
Contributor

Fenn-CS commented Dec 22, 2023

⚠️ This issue respects the following points: ⚠️

Bug description

A user encountered an issue when attempting to create share links in Nextcloud before 9:00 AM JST (UTC+09:00). After investigation, it appears there is an error in how we calculate share link expiration times, because looking at the code, we always use UTC irrespective of the users timezone.

Screenshot from 2023-12-22 06-10-47

Steps to reproduce

  1. Set the system clock to a time before 9:00 AM JST.
  2. Set a default expiration time (which is in number of days).
  3. Attempt to create a share link.

Expected behavior

Share links should be created without encountering any issues irrespective of the time of day.

Installation method

None

Nextcloud Server version

26

Operating system

None

PHP engine version

None

Web server

None

Database engine version

None

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

None

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

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

Configuration report

No response

List of activated Apps

No response

Nextcloud Signing status

No response

Nextcloud Logs

No response

Additional info

No response

@Fenn-CS Fenn-CS added the bug label Dec 22, 2023
@Fenn-CS Fenn-CS self-assigned this Dec 22, 2023
@Fenn-CS
Copy link
Contributor Author

Fenn-CS commented Dec 22, 2023

Likely culprits

$date = new \DateTime();
$date->setTime(0, 0, 0);
$date->add(new \DateInterval('P' . $defaultExpireDays . 'D'));
if ($date < $expirationDate) {
$message = $this->l->n('Cannot set expiration date more than %n day in the future', 'Cannot set expiration date more than %n days in the future', $defaultExpireDays);
throw new GenericShareException($message, $message, 404);
}

and

$date = new \DateTime();
$date->setTime(0, 0, 0);
$date->add(new \DateInterval('P' . $this->shareApiLinkDefaultExpireDays() . 'D'));
if ($date < $expirationDate) {
$message = $this->l->n('Cannot set expiration date more than %n day in the future', 'Cannot set expiration date more than %n days in the future', $this->shareApiLinkDefaultExpireDays());
throw new GenericShareException($message, $message, 404);
}

@Fenn-CS
Copy link
Contributor Author

Fenn-CS commented Dec 22, 2023

Recommended fix :

@ChristophWurst
Copy link
Member

  • defaults to 'Europe/Berlin'

Defaults to UTC. Europe/Berlin is an example.

@szaimen szaimen added 0. Needs triage Pending check for reproducibility or if it fits our roadmap 26-feedback labels Jan 2, 2024
@Fenn-CS Fenn-CS removed the 0. Needs triage Pending check for reproducibility or if it fits our roadmap label Jan 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

3 participants