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

set default time zone for date #154

Merged
merged 7 commits into from Oct 13, 2016
Merged

set default time zone for date #154

merged 7 commits into from Oct 13, 2016

Conversation

das7pad
Copy link
Contributor

@das7pad das7pad commented Oct 4, 2016

@pi-hole/dashboard

this prevents basic error messages from php(-cgi) for not setting the
timezone and then using UTC as default

PromoFaux and others added 2 commits October 1, 2016 16:24
this prevents basic error messages from php(-cgi) for not setting the
timezone and then using UTC as default
@PromoFaux
Copy link
Member

Not an error I've come across before, but I will test this and see if it breaks anything!

@PromoFaux
Copy link
Member

PromoFaux commented Oct 4, 2016

Approved

Not causing issues for me, but others may have a better insight. I'm not really a PHP guy!

Approved with PullApprove

@AzureMarker
Copy link
Contributor

I'm testing this now, to make sure that it doesn't force the timezone to be UTC if the server timezone is different.

@AzureMarker
Copy link
Contributor

While it does not affect data.php (because it reads in the dates from dnsmasq, which uses the system timezone), it does change how errors are logged from auth.php. Because of this, I would recommend that you make php use the system timezone.

this will imply the system time zone. command date and the given format
are supported by the majority of linux distros
trim against leading space from %k (range of ' 0' to '23') and
strtolower for AM/PM that %p outputs as uppercase, while 'a' (-> am/pm)
was used before
@das7pad
Copy link
Contributor Author

das7pad commented Oct 9, 2016

@Mcat12 So far I was not able to find a single solution to get the correct system time zone on most of the common linux distros within php. In addition there are incompatibilities between the output of the system and php. CEST for example can't be used by php and it's date_default_timezone_set.
So I came up with the system command date, which can be used for the actual time and also a given time as string. The basic format should work on most of the linux distros.

@AzureMarker
Copy link
Contributor

Looks great! Just one more thing.

@@ -125,7 +125,7 @@ function getAllQueries() {
$hostname = trim(file_get_contents("/etc/hostname"), "\x00..\x1F");

foreach ($dns_queries as $query) {
$time = date_create(substr($query, 0, 16));
$time = exec("date --date='" . trim(substr($query, 0, 16)) . "' +'%Y-%m-%d\%Z%H:%M:%S'");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this use the same format as before? Y-m-d\TH:i:s

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure! I thought the Timezone (T in php date) is used here and forgot about the function of the \ ^^

just output a 'T' insted of the Timezone
@AzureMarker
Copy link
Contributor

AzureMarker commented Oct 9, 2016

Approved

Approved with PullApprove

@PromoFaux
Copy link
Member

@das7pad had to revert this back out of the release, as it was causing issues. Happy to revisit, but we need to work out what it is doing to slow down the query page!

@akoebbe
Copy link
Contributor

akoebbe commented Oct 18, 2016

After looking over this change, I've got some concerns with making exec commands in the script, especially within iterators. In general it's a bad idea and I think we might be able to achieve the same result without needing to use exec. I'm happy to refactor this if there's no objection.

@PromoFaux
Copy link
Member

Suggestions and contributions always welcome!

@PromoFaux
Copy link
Member

Unless they're rubbish... ;)

@akoebbe
Copy link
Contributor

akoebbe commented Oct 18, 2016

Well forget it then. My default setting is "rubbish". :-)

@das7pad
Copy link
Contributor Author

das7pad commented Oct 19, 2016

ok, I can understand the performance issue here.

However not setting the timezone will spam the logfiles.

What about setting the timezone on a first run?
Check for existence and the then content of a file that will contain the timezone. If one fails, show the list of DateTimeZone::listIdentifiers() with a search functionality ( like https://silviomoreto.github.io/bootstrap-select/examples/#live-search )
In addition I would add a button to the top right menu to change the timezone later.

@akoebbe
Copy link
Contributor

akoebbe commented Oct 19, 2016

So there are a couple solutions to this problem.

  1. Check to see if a timezone is set and, if it's not, inform the user to update the php.ini file and set the timezone. Not every OS will set that property or has a patch for it. I guess this might be checked and fixed in the install script.
  2. Allow the user to update a setting by either updating a Pi Hole config file (setupVars.conf?) or a UI interface and then set the tz with date_default_timezone_set() at the beginning of the script. This would allow the user to specify a different tz for the admin vs another script they have running on the box. As far as I'm aware the only config file available is setupVars.conf. Maybe that can be populated during install based on the the OS's tz or add a step for the user to select it.

I don't think the TZ should be stored in the Admin code base since it's based on the tz of the log file the backend is generating. I'm not sure that putting the effort in to a Admin UI setting is worth it since it will only be set once and should probably be done during install.

@das7pad
Copy link
Contributor Author

das7pad commented Oct 19, 2016

@akoebbe
How would you check for the timezone? Using date_defaul_timzone_get() will spam the logfile.
The php.ini will be the default version in most cases and as you have said, this will be global - not the best idea.
From the OS we can't get a propper timezone that can be used in php date_default_timezone_set(). And printing the options from php during the installation is quite the same as entering a search query/scrolling down the list at the first run of the admin page.

The option in the dashbord later on would be just a call on the 'firstrun page' - which verifys the input and prints the timezone into another file, the admin scripts are then calling. Printing into the code of data.php or auth.php would break the ability to update I think.

@akoebbe
Copy link
Contributor

akoebbe commented Oct 19, 2016

@das7pad Where would you suggest the value selected be stored?

@akoebbe
Copy link
Contributor

akoebbe commented Oct 19, 2016

@das7pad We could check for the timezone with the getter function you mentioned and use the '@' to suppress warning messages on that call.

@das7pad
Copy link
Contributor Author

das7pad commented Oct 19, 2016

@akoebbe How about the php directory in a new file .timezone?

I am running Centos 7 and my Timezone is set to Europe/Berlin in timedatectl.
date +'%Z' outputs CEST
php -r 'echo @date_default_timezone_get();' outputs UTC as CEST is not a valid identifier in php for a timezone

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants