Solr Upgrade Pitfalls - Dates Spatial Fields and docValues

Three changes cause most of the surprises after a Solr upgrade. Check them before you reindex.

Date format must be UTC with literal Z suffix

Solr 9 DatePointField rejects timezone offsets like +02:00 at insert time. Older Solr was lenient and silently converted them. The Opensolr crawler and Data Ingestion API have already been updated to convert dates correctly. If you have your own indexer, update it:

// Solr 9 pdate REQUIRES UTC with the literal Z suffix.
// Timezone offsets like +02:00 are REJECTED at insert time.

// WRONG (Solr 9 will throw):
$doc["upload_date_dtm"] = "2026-04-02T15:11:07+02:00";

// RIGHT - convert in PHP before pushing:
$dt = new DateTime($input);
$dt->setTimezone(new DateTimeZone("UTC"));
$doc["upload_date_dtm"] = $dt->format("Y-m-d\TH:i:s\Z");

DocValues required for facet / sort / group on PointFields

TrieFields stored facet/sort information in their indexed terms. PointFields do not — they store BKD points only. To facet, sort, group, or use function queries on a numeric or date field, you must add docValues="true" on the fieldType (or on every <field> entry). Without it, every facet on that field returns zero buckets and Solr logs “can not sort on a field which is not indexed nor has doc values”.

Spatial: LatLonType is gone

If you used solr.LatLonType with a subFieldSuffix, replace it with solr.LatLonPointSpatialField. Stored values are still "lat,lon" string format on input. {!geofilt} and geodist() still work. Hidden _coordinate subfields are gone — rewrite any query that referenced them.

Solr migration