php-5.3 w/ apachesolr

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
alexus's picture

in our production environment (running redhat enterprise linux 5.7):

php -v

PHP 5.2.17 (cli) (built: Jan 11 2011 11:12:46)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies

in our proposed production environment (running redhat enterprise linux 6.1):

php -v

PHP 5.3.3 (cli) (built: Jan 21 2011 09:39:13)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies

the issue is that in php-5.3 something was revised in date(); function and that produces some issue for apachesolr project, such as: date shows incorrectly

did anyone had similar issues? i'm kind of stumble here and dont know what to do at this point...

Comments

what is wrong with date?

mihha's picture

what is wrong with date? where does it show incorrectly? what version of apachesolr?

here's one issue about date facets: http://drupal.org/node/558160
and here's some issue about strange behavior of apachesolr on jetty on debian 64bit after java update: http://drupal.org/node/1287860

Mihajlo

php 5.1x = date.timezone

Peter Bowey's picture

Since PHP 5.1.0 (when the date/time functions were rewritten), every call to a date/time function will generate a E_NOTICE if the timezone isn't valid, and/or a E_WARNING message if using the system settings or the TZ environment variable.

Instead of using this function to set the default timezone in your script, you can also use the INI setting date.timezone to set the default timezone.

There is a new (as of PHP 5.1) $_SERVER variable argument called "REQUEST_TIME". It holds the UNIX timestamp of the initiation of the call.

Date/time support has been fully rewritten in PHP 5.1.x, and no longer uses the system settings to 'know' the timezone in operation. It will instead utilize, in the following order:

The timezone set using the date_default_timezone_set() function (if any)

The TZ environment variable (if non empty)

"magical" guess (if the operating system supports it)

If none of the above options succeeds, UTC

You can use both the (new) $_SERVER['REQUEST_TIME'] variable or the (older) time()function. Both of these return a Unix timestamp.

Most of the time these two solutions will yield the exact same Unix Timestamp. The difference between these is that $_SERVER['REQUEST_TIME'] returns the time stamp of the most recent server request and time() returns the current time. This may create minor differences in accuracy depending on your application, but for most cases both of these solutions should suffice.

--
Linux: Web Developer
Peter Bowey Computer Solutions
Australia: GMT+9:30
(¯`·..·[ Peter ]·..·´¯)

What's new in PHP

Peter Bowey's picture

What's new in PHP 5.3.6:

DateTime extension:
· Fixed a bug in DateTime->modify() where absolute date/time statements had no effect. (Derick)
· Fixed bug #53729 (DatePeriod fails to initialize recurrences on 64bit big-endian systems). (Derick, rein@basefarm.no)
· Fixed bug #52808 (Segfault when specifying interval as two dates). (Stas)
· Fixed bug #52738 (Can't use new properties in class extended from DateInterval). (Stas)
· Fixed bug #52290 (setDate, setISODate, setTime works wrong when DateTime created from timestamp). (Stas)
· Fixed bug #52063 (DateTime constructor's second argument doesn't have a null default value). (Gustavo, Stas)

What's new in PHP 5.3.2:

· Fixed bug #50930 (Wrong date by php_date.c patch with ancient gcc/glibc versions). (Derick)
· Fixed bug #50392 (date_create_from_format() enforces 6 digits for 'u' format character). (Ilia)
· Fixed bug #49585 (date_format buffer not long enough for >4 digit years). (Derick, Adam)

--
Linux: Web Developer
Peter Bowey Computer Solutions
Australia: GMT+9:30
(¯`·..·[ Peter ]·..·´¯)

A note on

Garrett Albright's picture

A note on $_SERVER['REQUEST_TIME'] - while it's very handy in certain occasions to be able to take note of when the current web hit started, please don't assume that this variable will always be available. In particular, when Drush is used, there is no "server" in play and that variable won't be set. You should check for existence of the variable and fall back to time() if it's not there.

<?php
$time
= (isset($_SERVER) && isset($_SERVER['REQUEST_TIME'])) ? $_SERVER['REQUEST_TIME'] : time();
?>

If the variable isn't set but your code doesn't check for that, it'll get picked up as NULL, which might get interpreted as zero, and who knows what chaos that might cause.

<?phpdrush ev

greggles's picture

<?php
drush ev
"drush_print_r(\$_SERVER['REQUEST_TIME'])"
?>

Works for me?

What platform did you see where it doesn't work?

Huh. Works for me too. php -r

Garrett Albright's picture

Huh. Works for me too. php -r 'print($_SERVER["REQUEST_TIME"]);' even.

Well.

Ahem.

iwaswrong THERE, I SAID IT, OKAY?!

I'm using apache-solr-1.4.1

alexus's picture

I'm using apache-solr-1.4.1 w/ apachesolr 6.x-2.0-beta2. I also tried apache-solr-3.3.0 w/ same apachesolr.
i will include screenshot of what i'm talking tomorrow

Ok, I'd like to update this

alexus's picture

Ok, I'd like to update this discussion...

I've tried out apachesolr following versions: 6.x-1.5, 6.x-1.x-dev and 6-x-2.0-beta5 on apache-solr-3.4.0 (RHEL6.1).

All of them delivered same results: now I'm missing "Refine your search by" on the left side when I'm doing search inside of Drupal...

any ideas?