oh, and if you update it , do a test order and please let me know how it goes

try updating the paypal plugin to 2.1.7.7.
might actually in fact be down to me using a – now – old certificate in the ipn listener

2.1.7.7 uses inbuilt WP cert chains now (as opposed to using its own bundle), so updating WP will automatically also mean paypal uses that bundle instead (and is a much better approach anyway)

on second thoughts.
give me five minutes and i might be able to send you something you could try

>This is unchecked.
and it should be unchecked (in fact, i will take that option out one day altogether)

either way it’s your server (php/’curl) setup speak to your host or administrator
see also here (in general)

https://www.google.co.uk/?gws_rd=ssl#q=cURL+error:+%5B60%5D+SSL+certificate+problem:+unable+to+get+local+issuer+certificate

and here in particular

http://stackoverflow.com/questions/17478283/paypal-access-ssl-certificate-unable-to-get-local-issuer-certificate

what version of the paypal plugin ?

definitely something to do with using anchors . i’ll see what i can do

lol
>if UTC, convert the timestamp to WP time with some function, multiply by 1000’s

what i said there is of course nonsense.
one would recalc the current time to UTC once of course and then compare the db entries as opposed to recalculating every db entry and comparing them to current time..
anyway though, the rest still applies

first of all, the only times that actually get stored are the order and update time in the order table (as far as i remember anyway) and there is no calculation going on there as it just uses a mysql timestamp. (a bit more about this below)

secondly – and more importantly as far as i am concerned – consider the following:
store order time as UTC.
go to admin ->reports which – obviously – uses the times stored in the order table to figure out when was what order done.
if UTC, convert the timestamp to WP time with some function, multiply by 1000’s
if *not* UTC, do not run a function , multiply function to run by == 0
(same would be the case for various other places, just not that excessively)

furthermore. the order time SHOULD be fixed to the timezone here in my book.
if i make an order at 4PM at the timezone we are in it was still at 4PM 10 months later when the server moves elsewhere and their timezones are different, not suddenly at 6PM or 2PM or whatever

although nothing to do with reports, there seems to be a transient issue with wordpress under certain circumstances
https://wordpress.org/support/topic/set_transient-seem-to-use-server-time-regardless-of-timezone

lastly, i have also seen plugins that totally disregard other plugins and overwrite/change wp time with their own stuff screwing everybody else. So it does not make any difference what time YOUR plugin is using as someone else thinks THEIR time should be used

in any case, all of the above is not ever a problem if the timezones match.
i know of some hosting companies arguments , that the server time should be utc because visitors to the site come from all parts of the world. as far as i am concerned, this is complete rubbish as the server itself (and the shop that is running on that server) is NOT in different parts of the world but in a very distinct location

regarding the mysql timestamp. currently it inserts the time into the timestamp column by itself so to speak (there’s not insert time() into timestamp_column)

one could probably change that to do insert wp_time into timestamp_column which should at least overcome the times saved are being wp_times , regardless of php.ini settings.
i will mull this over for a bit

>What do you recommend about having this put in…
nothing.

if you want, you can put it in the feature request section, but absolutely no guarantees when (if ever) i will be able to do anything about this

these files are not modifiable.
you will never be able to update the plugin again …