[Rets-dev] Please clarify interpretation of Dates and Times

Thu Apr 5 15:29:55 CDT 2007

I'll try to make some room to discuss time in general, 
modficationTimestamp queries and this in specific. It'll probably be on 
the Friday. Even if we can't do a quick fix on RETS1, I think it would 
be good to make sure that we didn't leave the same problem for RETS2. 
There are still a small number of projects to build these systems 
(RETS2) so fixing it now (if necessary) would be good. Retro-fitting it 
to RETS1 may be more of a challenge.

Paul

Sergio Del Rio wrote:
>
> Very interesting indeed. I can understand differences between RETS 
> implementations on many areas in the specification; however, this is 
> one area where I thought it was very clear and was not open to 
> interpretation. It is also interesting that the compliance tool does 
> not actually address this, not sure how it could actually, but this is 
> clearly an area which is causing trouble for clients and most of the 
> server vendors have not realized this it seems.
>
> I guess putting the timezone into the metadata would have been the 
> better solution and would have left the burden of the timezone 
> calculations to the client. It would have also made the actual 
> timezone definition of the returned records unambiguous and more 
> easily allowed for a server to actually handle listings in multiple 
> timezones. Not sure if this is something we can change now, but I 
> think it would be a topic worth addressing at the April meeting…
>
> So, Paul, why don’t you put it on the agenda?
>
> Regards,
>
> Sergio Del Rio
>
> Templates 4 Business Inc.
>
> ------------------------------------------------------------------------
>
> *From:* jp.fielding at gmail.com [mailto:jp.fielding at gmail.com] *On 
> Behalf Of *JP Fielding
> *Sent:* April 5, 2007 12:00 PM
> *To:* Sergio Del Rio
> *Cc:* Tony Manhollan; rets dev mailing list
> *Subject:* Re: [Rets-dev] Please clarify interpretation of Dates and Times
>
> btw, congratulations sergio, i believe mris' rets is the only rets 
> server that ive run into yet that 'interprets' the search time as GMT. :-)
>
> others might 'accept' the time, as in they dont blow up, but if i 
> query listings against others server and send their localtime minus 
> one hour in GMT against the last mod time, during the middle of the 
> day, i get back counts of zero. obviously, this could be because 
> nothing was updated, but not _always_. we usually stretch this example 
> to show that any last mod time sent greater than now (some shift 
> towards GMT) always returns no results when we're testing for time 
> interpretations prior to talking with a rets server
>
> like i said, easy enough to work around once you know, thats why it 
> might be easier to just stipulate it in the metadata and ditch the 
> requirement. you could even allow for backwards compatibility by 
> defaulting to GMT if unspecified.
>
> On 4/5/07, *Sergio Del Rio* <Sergio.Del.Rio at t4bi.com 
> <mailto:Sergio.Del.Rio at t4bi.com>> wrote:
>
> The specification clearly states that times in queries are to be 
> transmitted in GMT, it even qualifies the statement with MUST. Any 
> server that does not accept queries in GMT would not be compliant to 
> the specification. The specification has never said that queries are 
> supposed to be incoming in local and returned in GMT, I am quite 
> certain about this.
>
> Regards,
>
> Sergio Del Rio
>
> Templates 4 Business Inc.
>
> ------------------------------------------------------------------------
>
> *From:* rets-dev-bounces at rets.org <mailto:rets-dev-bounces at rets.org> 
> [mailto: rets-dev-bounces at rets.org <mailto:rets-dev-bounces at rets.org>] 
> *On Behalf Of *JP Fielding
> *Sent:* April 5, 2007 7:42 AM
> *To:* Tony Manhollan
> *Cc:* rets dev mailing list
> *Subject:* Re: [Rets-dev] Please clarify interpretation of Dates and Times
>
> thats what the spec says, what servers do seems quite different. oddly 
> enough, i see some servers that take queries in local, and return in 
> gmt (the latter being a recommendation of the spec at one point, dont 
> recall if it still is). im dont recall any off the top of my head that 
> take queries in gmt.
>
> morale of the story, verify what the server is _supposed_ to do with 
> the vendor, and then sanity test it. the sanity test can be time 
> consuming, but necessary if you dont want over/underlap.
>
> On 4/5/07, *Tony Manhollan* <tony at realestatepointe.com 
> <mailto:tony at realestatepointe.com>> wrote:
>
> Hi,
>
> Could I get some clarification from the community on this please? 
> Regarding
> dates and times, section 7.7.2 of the RETS 1.5 spec says:
>
> > All datetimes submitted in queries MUST be in GMT. All other dates or 
> times
> > are interpreted in host time.
>
> I interpret this to mean any time I send to the server should be expressed
> in GMT. Any time the server sends back is expressed in local time for the
> server. Is this correct? And is host time meant to be the time where the
> server is located, or the time where the business operates whose data the
> server hosts. E.g.: If software vendor X, located in California provides
> services and hosting for MLS Y, located in New York, are times 
> returned by
> the server in X's time zone, Pacific or Y's time zone, Eastern?
>
> By my interpretation, to get all updates since my previous connection to a
> server, I should record the time in GMT that my connection starts (say 
> now,
> 2007-04-05T14:10:00). The next time I connect, I should execute a 
> query like
> (ModificationTimeStamp=2007-04-05T14:10:00+). Would a query like that be
> time-accurate? I don't want to miss updates, but I don't want a 5-hour
> overlap either. It appears the latter is happening on a server I'm 
> trying to
> sync with and I want to make sure I'm understanding that right.
>
> Thanks.
>
> Tony Manhollan
> Realestatepointe.com <http://Realestatepointe.com>
>
> _______________________________________________
> Rets-dev mailing list
> Rets-dev at rets.org <mailto:Rets-dev at rets.org>
> http://lists.rets.org/mailman/listinfo/rets-dev
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Rets-dev mailing list
> Rets-dev at rets.org
> http://lists.rets.org/mailman/listinfo/rets-dev
>   

-- 
Paul Stusiak
Falcon Technologies Corp.