'query' Cannot Parse Dates

[GeneralMaximus]

According to BeOS texts, 'query' should be able to parse dates and times in several different formats. This does not appear to be the case with Haiku's 'query' tool.

Examples:

1. last_modified > 08/01/09

2. last_modified > August 1, 2009

3. last_modified > 08012009

None of the above queries work as intended, and return unpredictable results.

NOTE: This page details several query formats: ​http://www.birdhouse.org/beos/bible/exc_query.html

[pulkomandy]

Note that ICU has some support for date formatting and probably also parsing. This may be put to use, if only to handle localized dates.

[axeld]

The third form is not supported, neither in BeOS, nor in Haiku; the book seems to be wrong (I just tested the former).

The "query" application has no special support for times, so you actually have to pass the argument enclosed in '%'.

The locale kit should indeed be used by the parsedate() functionality to support more time formats - the current time formats should continue to be supported, though.

[axeld]

Oh, btw, the results are very predictable: since it will parse those values to something close to zero, it will probably return all files.

[anevilyak]

Just a note here, this seems to be quite picky as to what date formats it supports...

last_modified >= '%08/03/2009%', last_modified >= '%today%', last_modified >= '%yesterday%' all yield the desired result, while for instance last_modified >= '%2009/08/03%' does not. Any documentation on what all formats are actually accepted by our parsedate()? At least the man page seems to indicate the latter should work as well.

[axeld]

There is a man page for parsedate()? IIRC all I could find back then was a Be Newsletter article about it when I implemented it. Anyway, the source is your friend, it contains a long list of what formats are supported. Looking at that, the last format should actually be supported, maybe it's a bug in there.

It's even tested in the ParseDateTest.cpp app, but that somehow does not even check the resulting time - whatever I thought when I wrote that. I'll have a look at it.

[axeld]

The parsedate() test app still runs fine, and also parses the above forms correctly.

[anevilyak]

Re: man page I was thinking of PHP's equivalent function and assumed it was something from POSIX, my mistake. Regardless though, please explain:

~> query "(last_modified >= '%08/05/2009%')" | wc -l
13
~> query "(last_modified >= '%2009/08/05%')" | wc -l
10768

parsedate() may be handling it correctly, but somewhere along the line something is going wrong here.

[anevilyak]

hrev32117 by the way.

[axeld]

How does an strace of the above calls differ (the call opening the query)?

If parsedate() managed to parse both in the same way, they should also end up with the same query.

[anevilyak]

Replying to axeld:

How does an strace of the above calls differ (the call opening the query)?

If parsedate() managed to parse both in the same way, they should also end up with the same query.

I'll check, but unfortunately won't be able to until after work (circa 8 hours from now). I take it the problem's not reproducible for you with the same queries?

[axeld]

No, I was looking into something else, and thought you had the time :-)

Actually, I just tried, and it's reproducible here, too. parsedate() apparently returns -1 for the latter form. I have no idea why this works in the test app, but not in the real thing. While it doesn't fit the original ticket, I'm going to reopen this one, and continue to track the issue here.