You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Miguel <mi...@juntadeandalucia.es> on 2013/03/05 18:21:07 UTC

incorrect datetime to use now function

Hi

   I am using timestamp field configured in the schema, so this way:

<field name="timestamp" type="date" indexed="true" stored="true" 
default="NOW" multiValued="false"/>

when I've checked the new data, I see datetime value have one hour less 
than current date.
I though it was problem on java configuration so I include in JAVA_OPTS 
= -Duser.timezone=Europe/Madrid
but the mistake go on.

I've looked for some kind of configuration about NOW function on Apache 
Solr, but I not found anything.
Any ideas?

thanks

Re: incorrect datetime to use now function

Posted by Miguel <mi...@juntadeandalucia.es>.
Hi Cris

    I've used TZ param with UpdateXmlMessages and data are indexed with 
default GMT value on field timestamp, but one hour less than current 
date system.

I am doing test using command curl, so:

/curl http://10.240.234.133:8080/solr/update?TZ=Europe/Madrid 
--data-binary @data.xml -H "Content-type:text/xml; charset=utf-8"/

where data.xml is a file and contains XML add message, like this:

/<?xml version="1.0" encoding="UTF-8"?>//
//<add>//
//  <doc>//
//    <field name="id">00000001A_01</field>//
//    <field name="key">disposition.1979.6.2</field>//
//    <field name="INTERNO">00000001A</field>//
//    <field name="PATH_PDF">d2</field>//
//    <field name="HASH" />//
//    <field name="ALGORITMO_HASH" />//
//    <field name="FIRMA" />//
//    <field name="FORMATO_FIRMA" />//
//  </doc>//
//</add>/

The xml message not contain timestamp field and I need solr include 
default value with current date system.
I am using solr version 1.4.1. May be, this solr version not allow TZ 
param ?


El 06/03/2013 19:20, Chris Hostetter escribió:
> :     I've used this configuration to my timestamp field and it's works
> :
> : <field name="timestamp" type="date" indexed="true" stored="true"
> : default="NOW+1HOUR" multiValued="false"/>
>
> that is *really* not a good idea ...
>
> doing something like that means you will be putting incorrect data into
> your index, saying a doc was added an hour lafter it realy was, and
> assuming that later when clients query your index they will just
> implicitly understand that the Date they get back in UTC is wrong
> and should be interpreted in a differnet way with a 1 hour "fudge factor"
> that will be even more wrong and more confusing anytime DST happens
>
>   * Solr indexes contain dates formatted in UTC
>   * Client's know their own TZ, and should read/write Date values Solr
> formated in UTC
>
> : Anyway, I would like to know possible configuration of TZ parameter. When  you
> : speak "clients can specify a "TZ" param", this means it is possible configure
> : TZ parameter using solrconfig.xml or schema.xml files ??
>
> it's not a configuration option, it's a query param that be used in
> requests where DateMath is involved.  so to find all documents indexed
> "yesterday" according to the conventions of when a day starts in the
> "Europe/Madrid" TimeZone, you can do a request like...
>
>    q=myField:[NOW-1DAY/DAY TO NOW/DAY]&TZ=Europe/Madrid
>
> ...and the *rounding* will be done realtive the specified timezone, but
> the Dates in the response will still be formated in UTC -- Solr can't
> assume that the client is also in Europe/Madrid, or that the client will
> understand what TZ an ambigious DateTime value of "2013-03-06T12:00:00" is
> in .. that's why the values are explicitly in UTC: "2013-03-06T12:00:00Z"
> (note the "Z" suffix)
>
>
>
> -Hoss
>


Re: incorrect datetime to use now function

Posted by Chris Hostetter <ho...@fucit.org>.
:     I've used this configuration to my timestamp field and it's works
: 
: <field name="timestamp" type="date" indexed="true" stored="true"
: default="NOW+1HOUR" multiValued="false"/>

that is *really* not a good idea ... 

doing something like that means you will be putting incorrect data into 
your index, saying a doc was added an hour lafter it realy was, and 
assuming that later when clients query your index they will just 
implicitly understand that the Date they get back in UTC is wrong 
and should be interpreted in a differnet way with a 1 hour "fudge factor" 
that will be even more wrong and more confusing anytime DST happens

 * Solr indexes contain dates formatted in UTC
 * Client's know their own TZ, and should read/write Date values Solr 
formated in UTC

: Anyway, I would like to know possible configuration of TZ parameter. When  you
: speak "clients can specify a "TZ" param", this means it is possible configure
: TZ parameter using solrconfig.xml or schema.xml files ??

it's not a configuration option, it's a query param that be used in 
requests where DateMath is involved.  so to find all documents indexed 
"yesterday" according to the conventions of when a day starts in the 
"Europe/Madrid" TimeZone, you can do a request like...

  q=myField:[NOW-1DAY/DAY TO NOW/DAY]&TZ=Europe/Madrid

...and the *rounding* will be done realtive the specified timezone, but 
the Dates in the response will still be formated in UTC -- Solr can't 
assume that the client is also in Europe/Madrid, or that the client will 
understand what TZ an ambigious DateTime value of "2013-03-06T12:00:00" is 
in .. that's why the values are explicitly in UTC: "2013-03-06T12:00:00Z" 
(note the "Z" suffix)



-Hoss

Re: incorrect datetime to use now function

Posted by Miguel <mi...@juntadeandalucia.es>.
thanks Cris

     I've used this configuration to my timestamp field and it's works

<field name="timestamp" type="date" indexed="true" stored="true" 
default="NOW+1HOUR" multiValued="false"/>

Anyway, I would like to know possible configuration of TZ parameter. 
When  you speak "clients can specify a "TZ" param", this means it is 
possible configure TZ parameter using solrconfig.xml or schema.xml files ??

Best regards.


El 05/03/2013 18:32, Chris Hostetter escribió:
> : when I've checked the new data, I see datetime value have one hour less than
> : current date.
>
> Please note the documentation about DateField (and TrieDateField which
> extends it)...
>
> https://lucene.apache.org/solr/4_1_0/solr-core/org/apache/solr/schema/DateField.html
>
> The response format is *always* in UTC so that it is consistent for all
> clients, regardless of what locale the server is running in -- because the
> clients may not *know* what locale the server is running in.
>
> If you use SolrJ then you will get java.util.Date objects back and you
> can format them in whatever local your client would like.
>
> Note however that clients can specify a "TZ" param when making requests to
> control the timezone used for the purposes of *rounding* -- eg: if you say
> "NOW/DAY" the TZ specified will determine when the start of the day is,
> but the resulting Date value will still be formated in UTC so it can
> consistently be interpreted in all clients.
>
> (Aparently the "TZ" param has never really been documented ... i'll try to
> rectify that)
>
>
> -Hoss
>
>


Re: incorrect datetime to use now function

Posted by Chris Hostetter <ho...@fucit.org>.
: when I've checked the new data, I see datetime value have one hour less than
: current date.

Please note the documentation about DateField (and TrieDateField which 
extends it)...

https://lucene.apache.org/solr/4_1_0/solr-core/org/apache/solr/schema/DateField.html

The response format is *always* in UTC so that it is consistent for all 
clients, regardless of what locale the server is running in -- because the 
clients may not *know* what locale the server is running in.

If you use SolrJ then you will get java.util.Date objects back and you 
can format them in whatever local your client would like.

Note however that clients can specify a "TZ" param when making requests to 
control the timezone used for the purposes of *rounding* -- eg: if you say 
"NOW/DAY" the TZ specified will determine when the start of the day is, 
but the resulting Date value will still be formated in UTC so it can 
consistently be interpreted in all clients.

(Aparently the "TZ" param has never really been documented ... i'll try to 
rectify that)


-Hoss