Closed rinchen closed 9 years ago
Also, in php.ini I've set
date.timezone = "America/Denver"
but that made no difference.
I believe the errors in this case are coming from the "Email Server" section of the Admin UI. Mail stopped working with the upgrade and I was attempting to send test emails via PHP and Sendmail. mail.err is empty and none of the other logs I've looked at seem to register mail being sent. My working assumption is that the mail is stuck in the mail queue handler. I'm using CRON as noted in the log.
Hi,
note that there are two different php.ini files:
/etc/php5/apache2/php.ini (used by the webserver) /etc/php5/cli/php.ini (used by the php-cli and so by your CRON)
Have you set the Timezones in both of them?
@RealRancor I didn't have it in cli. I've retested and the errors remain. Thanks for reminding me about it though. I could have sworn I added it but apparently not.
Hi all, Same error after upgrading on debian from OC 7 to OC 8. Also tried to define Timezone in both php.ini, but doesn't help. Always same error
Possible workaround : Edit emailnotification.php @ line 113 : $timezone = (isset($userTimezones[$user])) ? $userTimezones[$user] : date_default_timezone_get();
Okay, buta lets keep this issue open until the fix is merged
I don't think, hard setting UTC is a solution. Edit emailnotification.php like "phritter" said is much better (but not best) because this uses server values as default. @ line 113 : $timezone = (isset($userTimezones[$user])) ? $userTimezones[$user] : date_default_timezone_get(); (don't know, if this code really works)
Further notes, please see: https://github.com/owncloud/activity/pull/244
Will be in 8.0.3 and 8.1
@MorrisJobke I'm experiencing
DateTimeZone::__construct(): Unknown or bad timezone (/freeassociation.sourceforge.net/Tzfile/Europe/Berlin) at /var/www/owncloud/3rdparty/sabre/vobject/lib/Sabre/VObject/TimeZoneUtil.php#412
after upgrading to 8.0.3. Can I help to debug or should I reopen this ticket?
This looks weird. Like a offset, that isn't used, because the end of the time zone is correct, but the /freeassociation.sourceforge.net/Tzfile/
cc @nickvergessen
Yep. It kind of started with the upgrade to 8.0.3 (see thread https://twitter.com/dmfs_org/status/600221518153527296 because I suspected CalDAV sync to be broken :D)
@bascht did you use Evolution in the past? That TZID looks like the ones used by Evolution and it looks perfectly valid, given the corresponding VTIMEZONE object is valid as well. Also these TZIDs are around for quite some time (probably even longer than ownCloud supports CalDAV after all).
Please try to enable "Use WebDAV Method" in the settings of CalDAV-Sync. That could help working around this issue until it's fixed.
@dmfs I'm using the GNOME accounts on my desktop so there is probably still some Evolution syncing going on here. Are there any drawbacks of checking the "Use WebDAV Method" box?
@bascht It's slightly less efficient than what it does now, because it always syncs the entire calendar (even events way back in the past). But the server doesn't have to parse the calendar data, because it doesn't need to filter. So it's more robust on the server side when it comes to broken calendar data.
@dmfs Yep, the Evolution thing was a pretty good hint. I found & deleted that calendar entry and now the next one pops up:
DateTimeZone::__construct(): Unknown or bad timezone (W. Europe Standard Time) at \/var\/www\/owncloud\/3rdparty\/sabre\/vobject\/lib\/Sabre\/VObject\/TimeZoneUtil.php#412
@nickvergessen @MorrisJobke should I open a new issue? Looks like this is a regression in 8.0.3.
Yes new issue please
I can confirm seeing this error, example:
Error PHP DateTimeZone::__construct(): Unknown or bad timezone (W. Europe Standard Time) at /usr/share/owncloud/3rdparty/sabre/vobject/lib/Sabre/VObject/TimeZoneUtil.php#412 2015-05-31T08:11:25+00:00
On (Server: 8.0.2, Clients: 1.8.0) as well as now with (Server: 8.0.3, Clients 1.8.1). I have never used Evolution. I use Thunderbird/Lightning and Android CalDAV-Sync for syncing Calendars generally.
tzdata
reports this:
:/# dpkg-reconfigure tzdata
Current default time zone: 'Europe/Amsterdam'
Local time is now: Thursday 7 May 15:32:25 CEST 2015.
Universal Time is now: Thu May 7 13:32:25 UTC 2015.
For some reason phpinfo
reports Europe/Berlin
(although that is the same timezone), without manually setting date.timezone, that is:
date
date/time support enabled
"Olson" Timezone Database Version 0.system
Timezone Database internal
Default timezone Europe/Berlin
Slightly more info in my comments in https://github.com/owncloud/client/issues/3020
Howdy,
I'm not sure if I'm conflating two issues here or not but the errors here are quite similar. This started happened as far as I can tell after the upgrade to 8.0 from 7 via the Suse Build service repo. This error occurs on Ubuntu 14.04.1.
Steps to reproduce
Expected behaviour
No errors :-)
Actual behaviour
DateTimeZone::__construct() errors in own cloud.log (see below)
Server configuration
Ubuntu 14.04.1
Web server: apache2 2.4.9
Database: mysql 5.5.41
PHP version: php5 5.5.9
ownCloud version: owncloud 8.0.0-5
Updated from an older ownCloud or fresh install: updated via repo
List of activated apps:
I should point out that I disabled calendar because I was also seeing these message in the calendar app sporadically. I left the Calendar app disabled for troubleshooting.
The content of config/config.php:
Are you using external storage, if yes which one:
data directory is mapped in the config to /dev/sdb1 /srv/owncloud/ ext4 defaults 0 1
Are you using encryption: no
Logs
Web server error log
There are no errors in apache2 error.log
ownCloud log (data/owncloud.log)