OK, great. No worrying about which time zone the server is running in with Solr, LOL! Databases and server side languages and cron scripts OTOH . . .
Dennis Gearon Signature Warning ---------------- It is always a good idea to learn from your own mistakes. It is usually a better idea to learn from others’ mistakes, so you do not have to make them yourself. from 'http://blogs.techrepublic.com.com/security/?p=4501&tag=nl.e036' EARTH has a Right To Life, otherwise we all die. --- On Fri, 10/8/10, Jan Høydahl / Cominvent <jan....@cominvent.com> wrote: > From: Jan Høydahl / Cominvent <jan....@cominvent.com> > Subject: Re: having problem about Solr Date Field. > To: solr-user@lucene.apache.org > Date: Friday, October 8, 2010, 3:46 AM > Correct. You get back what you push > in. > > Of course if your index is for users in one time zone only, > you may insert the local time to Solr, and everything will > work well. However, if you operate an index with > international users, you'd want to make sure you convert > to/from UTC in your application on the borders of Solr. > > That's why the date string you send to Solr is formatted > like yyyy-mm-ddTHH:MM:ssZ - the Z at the end means Zulu, so > it's very explicit. > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > > On 8. okt. 2010, at 09.11, Dennis Gearon wrote: > > > So where does translation take place between the > QUERIER's time zone, and the eventual VIEWER's time zone? > > > > That is done all at the application level? > > > > Dennis Gearon > > > > Signature Warning > > ---------------- > > It is always a good idea to learn from your own > mistakes. It is usually a better idea to learn from > others’ mistakes, so you do not have to make them > yourself. from > 'http://blogs.techrepublic.com.com/security/?p=4501&tag=nl.e036' > > > > EARTH has a Right To Life, > > otherwise we all die. > > > > > > --- On Thu, 10/7/10, Lance Norskog <goks...@gmail.com> > wrote: > > > >> From: Lance Norskog <goks...@gmail.com> > >> Subject: Re: having problem about Solr Date > Field. > >> To: solr-user@lucene.apache.org > >> Date: Thursday, October 7, 2010, 5:06 PM > >> Solr stores dates in UTC. There is no > >> timezone conversion or other > >> date-format processing in Solr. The admin screen > only shows > >> in UTC. > >> > >> ------ I want to get local time(JST) on Solr > Admin. > >> > >> On Wed, Oct 6, 2010 at 9:14 AM, Gora Mohanty > <g...@mimirtech.com> > >> wrote: > >>> On Wed, Oct 6, 2010 at 9:17 PM, Kouta Osabe > <kota0919was...@gmail.com> > >> wrote: > >>>> Hi, Gora > >>>> > >>>> Thanks for your advice. > >>>> > >>>> and then I try to write these codes > following your > >> advice. > >>>> > >>>> Case1 > >>>> "pub_date" column(MySQL) is 2010-09-27 > 00:00:00. > >>>> > >>>> I wrote like below. > >>>> > >>>> SolrJDto info = new SolrJDto(); > >>>> TimeZone tz2 = > TimeZone.getTimeZone("UTC+9"); > >>>> Calendar cal = Calendar.getInstance(tz2); > >>>> // publishDate represent "publish_date" > column on > >> Solr Schema and the > >>>> type is "pdate". > >>>> info.publishDate = > >> rs.getDate("publish_date",cal); > >>>> > >>>> then I got "2010-09-27T00:00:00Z" on Solr > Admin. > >>>> This result is what I expected. > >>>> > >>>> Case2 > >>>> "reg_date" column(MySQL) is 2010-09-27 > 11:22:33. > >>>> > >>>> I wrote like below. > >>>> TimeZone tz2 = > TimeZone.getTimeZone("UTC+9"); > >>>> Calendar cal = Calendar.getInstance(tz2); > >>>> info.publishDate = > rs.getDate("reg_date",cal); > >>>> > >>>> then, I got "2010-09-27T02:22:33Z" on Solr > admin. > >>>> this result is not what i expected. > >>> [...] > >>> > >>> It seems like mysql is doing UTC conversion > for one > >> column, > >>> and not for the other. I can think of > two possible > >> reasons for > >>> this: > >>> * If they are from different mysql servers, it > is > >> possible that the > >>> timezone is set differently for the two > servers. > >> Please see > >>> http://dev.mysql.com/doc/refman/5.1/en/time-zone-support.html > >>> for how to set the timezone for mysql. > (It is also > >> possible for > >>> the client connection to set a > connection-specific > >> timezone, > >>> but I do not think that is what is > happening here.) > >>> * The type of the columns is different, e.g., > one > >> could be a > >>> DATETIME, and the other a > TIMESTAMP. The mysql > >> timezone > >>> link above also explains how > these are handled. > >>> > >>> Without going through the above could you not > just set > >> the timezone > >>> for "reg_date" to UTC to get the result that > you > >> expect? > >>> > >>> Regards, > >>> Gora. > >>> > >> > >> > >> > >> -- > >> Lance Norskog > >> goks...@gmail.com > >> > >
