Handling of Locally Stored DateTime Objects When TimeZoneOffset Metadata Changes Due to Daylight Savings

[Eric Watts]

Hi All,

Curious if there are best practices around storing DateTime data when pulled from the feed - especially when the feed's TimeZoneOffset changes throughout the year due to Daylight Savings.

Issue at Hand:

• My feed's TimeZoneOffset changed from -07:00 to -08:00 due to Daylight Savings
• All DateTime strings returned from feed do not include an offset (eg: ModificationTimestamp = "2020-04-22 15:20:25")
• I'm currently storing the DateTime objects exactly as they are given - which directly relate to the TimeZoneOffset at the time I pulled that particular set of data but may be different from other data I have stored depending on when that data was last downloaded

In summary, I currently have a lot of DateTime data that was absorbed in -07:00 but all new data is being captured in -08:00. 

My Dilemma:

• I would like to have all data represented as accurately as possible (so having some dates stored referencing different timezone offsets seems a bit wacky)

Proposed Solutions:

• I could add a TimeZoneOffset column to each of my local tables so I could store the TimeZoneOffset for each recored - and update it whenever I get fresh data for that record
• I could convert all DateTime strings from their local representations to their UTC counterpart (ie: interpret the raw string of "2020-04-22 15:20:25" to be "2020-04-22 15:20:25-08:00" and convert that DateTime object to UTC timezone before persisting to my local database.

Anybody have any suggestions on handling this type of scenario?  My first thought was to convert all dates to UTC and store that but then I thought debugging date issues might be a pain (ie: trying to figure out why my locally stored date does not match up to the data fetched from the feed, etc - if I had a bug in my code for some reason). 

Any thoughts or suggestions are much appreciated,

Eric 

[mark enriquez]

The language itself should automatically handle that in it's datetime class....

-mark

--
You received this message because you are subscribed to the Google Groups "PHRETS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to phrets+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/phrets/91a181e0-f1e1-4652-ae87-2e3b02487487n%40googlegroups.com.

[Eric Watts]

The question was more geared towards what the best practices around storing references to the date/times provided by the MLS and not on how to instantiate a DateTime object w/ a timezone as that is trivial. 

In short: I've just started converting and storing all references to the date/times fetched from the feed in UTC. I've also started to only query the feed using UTC so I don't have to constantly shift between multiple timezones.

TLDR:

My server runs in UTC. The RETS feed I am pulling from yields date/time strings like "2020-04-22 15:20:25". So, if I were to do new \DateTime("2020-04-22 15:20:25"), I would get that date interpreted in UTC and not the feed's local time which is either "-07:00" or "-08:00" depending on the time of year. 

What I have begun doing is grabbing the date/time string and setting the timezone offset if one exists in the RETS metadata. If none is provided, I assume it is given in UTC.  My current implementation for date/time strings fetched from RETS is similar to:

// Instantiate date in RETS local timezone, if provided. Fallback to server time (UTC)
$dateTime = null !== $timeZoneOffset
    ? new \DateTime($timestamp, new \DateTimeZone($timeZoneOffset))
    : new \DateTime($timestamp);

// Convert instantiated date to UTC

$dateTime->setTimezone(new \DateTimeZone('UTC'));

// Store locally...

[mark enriquez]

So your basically rebuilding the properties and methods that already exist in the DateTime object bcuz I'm almost certain it stores the time in UTC already...

To view this discussion on the web visit https://groups.google.com/d/msgid/phrets/6f375423-157d-4c26-abcc-9489dc584c1bn%40googlegroups.com.

[mark enriquez]

In my experience with PHP, Python, and Java....DateTime classes are always very feature rich and can handle daylight savings and timezones easily. Since so much of what a computer does with business requires date and time considerations...it would only make sense these classes do it all.

[Eric Watts]

Where in my example am I rebuilding the properties and methods? In the provided example, I am leveraging the methods directly on the DateTime and DateTimeOffset classes.

[mark enriquez]

Ok...I think I understand your post better now.  The thing I was stuck on was..in general, it is impossible to know what timezone the RETS server is using, as it's possible the RETS provider could be using cloud servers from anywhere in the world.  Since the unix timestamp is always given in UTC, I was just figuring that you were converting all RETS timestamps to unix timestamps and thus getting UTC automatically.

Using gmdate("Y-m-d H:i:s") or time() gives you UTC.  You should then use date_default_timezone_set(YOUR_TIIMEZONE) as the default timezone to get the localized datetime when needed...the idea of passing around timezones in datetime constructors seems like a rather bad idea to me...





regards,

- mark


To view this discussion on the web visit https://groups.google.com/d/msgid/phrets/6f375423-157d-4c26-abcc-9489dc584c1bn%40googlegroups.com.

[Eric Watts]

Ya, I figured we were having some sort of miscommunication. 

So I guess where my head was at was that in RETS 1.7.2 they added metadata to the RETS connection that advertises the local timezone of the RETS server (https://github.com/troydavisson/PHRETS/wiki/Timezone-Handling).  The RETS server I am connecting to was returning "-07:00" and then once daylight savings hit it changed to "-08:00". This is what spawned my spiraling into trying to figure out the best way to handle RETS dates/times with timezones, etc. From my research RETS 1.7.2 servers MAY utilize the timezone offset relative to UTC and if they do, all date/time strings returned in the results must be in that timezone - no matter what timezone offset you send in your query. So, when I get "2020-04-22 15:20:25" returned from my RETS server it implicitly means ""2020-04-22 15:20:25-08:00". So, this is why I was constructing the date/time with the RETS server local time and then converting to UTC before I persist to my database - does that make sense? 

[Catalin Banu]

Store the date locally in UTC timezone

The RETS server will give you it’s timezone so you can make any tranformation. 

Sent from my iPhone

On 14 Nov 2020, at 02:16, Eric Watts <ericw...@gmail.com> wrote:

Where in my example am I rebuilding the properties and methods? In the provided example, I am leveraging the methods directly on the DateTime and DateTimeOffset classes.

To view this discussion on the web visit https://groups.google.com/d/msgid/phrets/f332cbea-9c51-49df-ae79-98299c2a7e0dn%40googlegroups.com.