-
Notifications
You must be signed in to change notification settings - Fork 113
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
Use colon :
for timezone layout when parsing dates
#2322
Comments
Could we use UTC offset instead of Zulu? Other than that I agree we should stick to a format, as both |
Sure 👍 |
Actually I'm wrong. This is how UTC is defined in ISO 8601 😅 we just need to agree in a format. This issue should be a ticket for the fast-lane. |
|
the oc10 code does this: /**
* Make sure that the passed date is valid ISO 8601
* So YYYY-MM-DD
* If not throw an exception
*
* @param string $expireDate
*
* @throws Exception
* @return \DateTime
*/
private function parseDate($expireDate) {
try {
$date = new \DateTime($expireDate);
} catch (Exception $e) {
throw new Exception('Invalid date. Format must be YYYY-MM-DD');
}
if ($date === false) {
throw new Exception('Invalid date. Format must be YYYY-MM-DD');
}
$date->setTime(0, 0, 0);
return $date;
} So it seems to rely on PHP magic detection of the format and ignores the time / sets it to 0. |
The
ParseTimestamp()
method currently uses2006-01-02T15:04:05Z0700
as layout for parsing dates. This is somewhat inconsistent and suboptimal for oC Web, we'd rather expect2006-01-02T15:04:05Z07:00
as the layout already uses delimiters like-
and:
.Is there a chance to align that? Otherwise we would need to implement a custom format in oC Web as well.
reva/internal/http/services/owncloud/ocs/conversions/main.go
Line 294 in d270f61
The text was updated successfully, but these errors were encountered: