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 Chris Hostetter <ho...@fucit.org> on 2011/03/02 03:30:26 UTC
Re: More Date Math: NOW/WEEK
: Digging into the source code of DateMathParser.java, i found the following
: comment:
: 99 // NOTE: consciously choosing not to support WEEK at this time,
: 100 // because of complexity in rounding down to the nearest week 101
: // arround a month/year boundry. 102 // (Not to mention: it's not clear
: what people would *expect*)
:
: I was able to implement a work-around in my ruby client using the following
: pseudo code:
: wd=NOW.wday; "NOW-#{wd}DAY/DAY"
the main issue that comment in DateMathParser.java is refering to is what
the ambiguity of what should happen when you try do something like
"2009-01-02T00:00:00Z/WEEK"
"WEEK" would be the only unit where rounding changed a unit
*larger* then the one you rounded on -- ie: rounding day only affects
hours, minutes, seconds, millis; rounding on month only affects days,
hours, minutes, seconds, millies; but in an example like the one above,
where Jan 2 2009 was a friday. rounding down a week (using logic similar
to what you have) would result in "2008-12-28T00:00:00Z" -- changing the
month and year.
It's not really clear that that is what people would expect -- i'm
guessing at least a few people would expect it to stop at the 1st of the
month.
the ambiguity of what behavior makes the most sense is why never got
arround to implementing it -- it's certianly possible, but the
various options seemed too confusing to really be very generally useful
and easy to understand
as you point out: people who really want special logic like this (and know
how they want it to behave) have an easy workarround by evaluating "NOW"
in the client since every week has exactly seven days.
-Hoss
Re: More Date Math: NOW/WEEK
Posted by Andreas Kemkes <a5...@yahoo.com>.
Thank you for the clarification.
Personally, I believe it is correct for a week to start in a different
month/year and it is certainly what I would expect. As you pointed out, these
time units don't form a strictly ordered set (...>year>month>day>...,
week>day...).
Complications arise from the different notions of what the first day of the week
is (Sunday - US and Canada, Monday - Europe and ISO 8601, Saturday - Middle
East). This is handled by the locale, I think.
Further complications are introduced by week numbering, but I don't think this
applies here (http://en.wikipedia.org/wiki/Seven-day_week#Week_numbering).
Both MySQL
(http://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html#function_yearweek)
and Postgres have the notion of weeks.
All this ignores complications of 5-day or 6-day weeks, which were used in
Russia during certain parts of the last century. There might be other
historical cases or even current ones, but as you, I believe a definition like
"A week is a time unit equal to seven days." is commonly accepted.
But maybe you are correct and this is special logic and belongs in the client.
Regards,
Andreas
________________________________
From: Chris Hostetter <ho...@fucit.org>
To: solr-user@lucene.apache.org
Sent: Tue, March 1, 2011 6:30:26 PM
Subject: Re: More Date Math: NOW/WEEK
: Digging into the source code of DateMathParser.java, i found the following
: comment:
: 99 // NOTE: consciously choosing not to support WEEK at this time,
: 100 // because of complexity in rounding down to the nearest week 101
: // arround a month/year boundry. 102 // (Not to mention: it's not
clear
: what people would *expect*)
:
: I was able to implement a work-around in my ruby client using the following
: pseudo code:
: wd=NOW.wday; "NOW-#{wd}DAY/DAY"
the main issue that comment in DateMathParser.java is refering to is what
the ambiguity of what should happen when you try do something like
"2009-01-02T00:00:00Z/WEEK"
"WEEK" would be the only unit where rounding changed a unit
*larger* then the one you rounded on -- ie: rounding day only affects
hours, minutes, seconds, millis; rounding on month only affects days,
hours, minutes, seconds, millies; but in an example like the one above,
where Jan 2 2009 was a friday. rounding down a week (using logic similar
to what you have) would result in "2008-12-28T00:00:00Z" -- changing the
month and year.
It's not really clear that that is what people would expect -- i'm
guessing at least a few people would expect it to stop at the 1st of the
month.
the ambiguity of what behavior makes the most sense is why never got
arround to implementing it -- it's certianly possible, but the
various options seemed too confusing to really be very generally useful
and easy to understand
as you point out: people who really want special logic like this (and know
how they want it to behave) have an easy workarround by evaluating "NOW"
in the client since every week has exactly seven days.
-Hoss