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

Thu Apr 5 14:58:49 CDT 2007

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> 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: <mailto:rets-dev-bounces at rets.org>
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> 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

_______________________________________________
Rets-dev mailing list
Rets-dev at rets.org
http://lists.rets.org/mailman/listinfo/rets-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rets.org/pipermail/rets-dev/attachments/20070405/e2c4ea87/attachment.html