lionit

Update on this subject, I have received reply from the team.
Hopefully the cause lied only in a communication error and everything will proceed smoothly from here.

At the present stage the issue can be considered resolved from my side.

Hi guys,
I appreciate the reply, but allowed some more time to pass and no reply yet.
Do you have any timeline about when you plan to reply to my questions?

I estimate that more than two weeks passed now from my first contact.
I do not want support for premium version here, I want to know if there is support, in any form or way.

Kindly provide me a mean to contact you in a reliable way.

Best regards,
Alessandro

Hi Nate,

ok, the issue is that my server clock was configured on AEST time (+11).
Now I’ve forced UTC time on it and everything is solved.

I was totally convinced that PHP functions did not care about that and would exclusively follow the php.ini, but it seems that it is not always the case.

Actually I had another funny output on:
echo date_default_timezone_get() . ' => ' . date('e') . ' => ' . date('T');
as it gave me UTC => UTC => EST

Thanks for the time you spent on this.
I will leave to you the marking it as resolved in case you need to add further pointers for others.

Thanks,
Alessandro

Hi Nate,

this is the best part of our job…isn’t it? ??

I only added an <?php echo get_option(‘gmt_offset’); ?> exclusively on the footer to understand if WP was taking the correct offset (and it does).

I should remove it indeed, now that we’ve pinpointed the issue.

php.ini is fine (set to UTC, double checked it from the central server /etc/php.ini and through a phpinfo file) and I’ve deleted the .htaccess, restarting the Apache service.

The datetime at runtime is fine too, I’ve removed that as you instructed previously (even if that workaround did the trick for your plugin). Honestly…I cannot think of what may be causing the issue and I’m actively searching for it.
But I know that gmdate() seems to output the correct time on a test string and that WordPress config page is able to display the correct time as you’ve seen, so the issue is confined to date().
I think that switching all the date() to gmdate() should be fine for me here and should not cause havoc on other plugins or WP core, but I’ll wait your opinion prior to commit the change.

Thanks,
Alessandro

Hi Nate,

Theme switching doesn’t change anything.
Disabling your plugin (the only one left activated during all the tests) doesn’t bring any appreciable result.

Look at the result

It seems that date likes to add the Timezone offset for whatever reason…on my server at least.

Note that maybe using gmdate instead of date could help resolving the problem without going to modify things on the entire php environment. Let me know what do you think about it.

Thanks,
Alessandro

Hi Nate,

here are the last shots about the info you asked.
Error displayed

Settings>general

Later I will try to scout on the interactions between the date function and the server settings; at least now I know from where everything starts. In the meantime any further pointer is greatly appreciated…and thanks for your passion!

Thanks,
Alessandro

This is what I was trying to do, but my ancient C++ skills required me more headbanging on this php code…
And the result is…AH! I would have never thought at that! That small date function seemed so innocent and straightforward on its own.

Basically the issue was on the formatting made by the date function to the timestamp. It formatted the timestamp obtained adding the full GMT offset of the server (+11).

As a quick workaround I’ve used
date_default_timezone_set(‘Europe/Rome’);
on top of the file and it did the trick (also for the other output on the page footer, so it works globally on the php instance it seems).

But it is not a pretty solution in my opinion and, while it may be made “portable” simply using a variable that extract the time zone from wordpress configuration, I think that something should be resolved elsewhere, either using a different function to format the date or fixing the root problem on the date function.

Thanks for helping me reach the root!
Alessandro

Hi Nate,

the issue is still present even after removing the .htaccess and restarting the server (UTC setting confirmed again by phpinfo).
Last try

I have edited the .htaccess previously in the effort to remove the possible issues caused by the server based in a different timezone. But as you can see in the screenshot the result of current_time(‘timestamp’) is, and has always been, coherent with the settings on WordPress.
I cannot understand from where this issue originates.

Thanks,
Alessandro

Just an update,

I’ve tested it on the online Australian server I use.
To filter out some variables I’ve disabled the late booking option.
I have also disabled all the other plugins and reverted to Twelve Fifteen theme with only the most basic edits to show the results.

I’ve configured, through .htaccess file on that share, the Time Zone for php.ini and the Server Time Zone to Rome.
Wordpress is set up to use Rome Time Zone.

Now comes the fun, please look at the following images
Not working case
First working case
It seems to compare the time to a reference 11 hours ahead (the current deviation from GMT time for Melbourne), ignoring the WordPress locale settings, any other settings or even the server time (going an hour ahead of it; changing it centrally through command line doesn’t bring any effect too).

If the current time is 7 (Rome Time) I would have to go at least 11 hours ahead of that, or 1 hour ahead of the current Melbourne time, to 18 to make it accept the input.

I have tried both with the old, working installation (and database) from my local test environment and with a fresh one.

My, limited, understanding is that the used code is already based on the UTC time (as it should be to avoid this kind of troubles), so why it doesn’t work is a mystery to me to date.
All I know is that it does ignore the WordPress settings anyway.

I need to fix that as I’m not sure where the server that will host this website will be geographically located (or even if it will have to stay on my server), so if there is an issue with this kind of setup I need to track it down.

I will try again with another fresh installation later.
In the meantime, thanks for your help!
Alessandro

Hi Nate,

thanks for your answer. Correct timezone from WP double checked.
I did a few experiments in the local test environment, disabling all plugins and reverting to Twelve Fifteen with very basic edits on index and footer templates to make everything is needed to show up.

As you can see here the issue about “bookings can not be made in the past” is still there. https://drive.google.com/file/d/0B-zq4G1enD3uTjFoZ1Noa3ZVdDQ/view
The current if cycle disables it entirely if a late booking limit is inserted.
I know that this is a small detail, but it may be nice to nest another if there to send a specific message telling that a time in the past has been selected AND that the booking has to be X minutes in advance. It would offer added feedback to an user that, for whatever reason, is selecting a wrong time.

About the late booking, it is working correctly now on the local test environment with all plugins and theme on, but the result has been unreliable before and the whole code seems to be spotless for me…I’m still puzzled.
Will try to collect more info and offer you a detailed report should it misbehave again on the test or production server.

Thanks for your help!
Alessandro