Opened 8 years ago

Last modified 8 years ago

#4181 reopened bug

'query' Cannot Parse Dates

Reported by: Ankur Sethi Owned by: axeld
Priority: normal Milestone: R1
Component: System/libroot.so Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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
  1. last_modified > August 1, 2009
  1. 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

Change History (11)

comment:1 Changed 8 years ago by 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.

comment:2 Changed 8 years ago by axeld

Resolution: invalid
Status: newclosed

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.

comment:3 Changed 8 years ago by 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.

comment:4 Changed 8 years ago by Rene Gollent

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.

comment:5 Changed 8 years ago by 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.

comment:6 Changed 8 years ago by axeld

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

comment:7 Changed 8 years ago by Rene Gollent

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.

comment:8 Changed 8 years ago by Rene Gollent

hrev32117 by the way.

comment:9 Changed 8 years ago by 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.

comment:10 in reply to:  9 Changed 8 years ago by Rene Gollent

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?

comment:11 Changed 8 years ago by axeld

Component: Kits/Storage KitSystem/libroot.so
Resolution: invalid
Status: closedreopened

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.

Note: See TracTickets for help on using tickets.