[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-636?pag... ] Sanne Grinovero commented on HSEARCH-636: ----------------------------------------- Hi Marc, are you considering the timezone? all index dates are encoded in UCT, that's the only reliable way. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-636?pag... ] Marc Schipperheyn commented on HSEARCH-636: ------------------------------------------- Well, I *was* working on this around midnight. So you might be right. I'll refactor back and see if I can preproduce -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-636?pag... ] Sanne Grinovero commented on HSEARCH-636: ----------------------------------------- I'm puzzled as nobody ever saw this problem before, so it's likely a regression in Lucene; would you provide a testcase? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-636?pag... ] Sanne Grinovero commented on HSEARCH-636: ----------------------------------------- You're not the first one having trouble with timezones. I'm wondering, should people willing to do a query on date ranges actually use resolution.HOUR, so that matches are returned in the proper range according to their timezone, othewise you have "some hours" which might result on different dates. That would avoid your issue right? I'd be glad to accept a documentation patch do add a short warning to consider this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-636?pag... ] Sanne Grinovero commented on HSEARCH-636: ----------------------------------------- well the docs already have a warning about storing in GMT. What I was referring to is that even if you store all dates in GMT (on both index and database, that's usually recommended anyway), when people enter a query they intuitively mean their own timestamp, and don't even think about possible daylight changes in both past and future. So your user interface will convert the "date string" entered by the user considering a timezone, for example what the user preferences have set, but then there's still a shift as the "now()" meant by the user might be a different date in GMT than the date the user would intuitively expect. Choose a point in time, if you write down the hour (no minutes needed) of it and then convert date+hour to GMT, you get the possibility to define query ranges in the 1h-step, so enabling you to make a date query on the index considering as rage limits not the GMT day beginning and end but the _user localized_ idea of "day start" and "day end". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira