On 18-Oct-07, at 11:43 AM, Chris Hostetter wrote:
: This is easy--I always convert dates to UTC. Doubly important
since several
: of our servers operate in different timezones.
:
: Less easy is changing Solr's interpretation of NOW in DateMath to be UTC.
: What is the correct way to go about this?
You lost me there ... "Dates" in java have no concept of timezone, they
are absolute moments in the space/time continuom. timezones only affect
the parsing/formating of dates. "NOW" is whenever Solr parses the string,
and when Solr then formats that Date as a string, it formats it in UTC.
Ah, that is good. So if:
$ date
Thu Oct 18 12:07:42 PDT 2007
Then NOW in Solr will be the absolute date Thu Oct 18 04:07:42 2007
(which is the current time in UTC)?
i'm guessing you are refering to the notion of rounding down the the
nearest "day" (or anything of less granularity) ... this is currently
hardcoded to be done relative UTC -- but as I mention, this is the type of
thing where ideally Solr would have a setting to let you specify which
timezone the rounding should be relative to.
I'm not sure this is desirable. If your user's are all over the
world, you'd ideally want to round to _their_ timezone, but I don't
see how this is realistic.
We had the same general issue just a few months ago. We can generate
reports on things like SCM commit activity for a given day. For
larger customers, they have users in multiple timezones - so what is
"the" timezone to use?
I wrote a blog post about it at http://blog.krugle.com/?p=267, but
the short answer is that ultimately we decided to use UTC for all
times (server, report, API, and UI) as the least heinous of the
various options.
-- Ken
--
Ken Krugler
Krugle, Inc.
+1 530-210-6378
"If you can't find it, you can't fix it"
