Rets Open House Datetimes about rets HOT 3 CLOSED

ISO8601. Always use this for storage and serialization of your time data.

Grab the timezone from the metadata (unfortunately, this isn't easy) or store it with your definition for an MLS. Take your DateTime and openhouse_time.change(offset: mls_offset) to set the right time zone. Then use it like normal.

from rets.

Open house times are a pretty odd, most of the ones I've seen come as a string, something like 1pm-3pm which is (usually) in the local time. How we parse this depends on the mls and what they give us, but we end up storing all of them as strings, similar to the sample above. We keep the raw data from the rets server around too, in case we need to reprocess those strings, but the strings can be used directly on the website, not requiring any processing.

I'm not sure this is the best solution, but it's pragmatic and works well for us. This has the downside that we can't search our database for open houses by time, but in practice we've never really needed that and for the majority of mlses we do minimal processing to format the string.

If you do need to search by open house times, normalizing the times and storing in two columns (or a range column if you're in postgresql!) as @timdorr suggests is probably best.

from rets.

Thanks for the info! Much appreciated 😄 . We have settled on a similar approach... storing as is.

If, as you said, there is no need to search by time or show an open house time in a different timezone, then might as well save yourself the complexity and store as is.

@timdorr Unfortunately, you can't rely on an mls offset all the time because the mls may span multiple timezones and, as I recently noticed, the tz offset that an mls may advertise does not correct for DST.

from rets.