Timezone

[toddstoker]

DateTime objects in the SDK are incorrect. It looks like they are being built by parsing the date string from Infusionsoft (which represents an Eastern date/time) but the object is initialized as UTC rather than Eastern.

[Avidproducers]

@toddstoker

DateTime objects in the SDK are incorrect. It looks like they are being built by parsing the date string from Infusionsoft (which represents an Eastern date/time) but the object is initialized as UTC rather than Eastern.

Are you saying this SDK converting wrong? If so what version number are you seeing this in?

On the other hand I am pretty sure this is not a bug as it should be set to UTC on purpose. UTC is the time standard commonly used across the world. Coordinated Universal Time (UTC) is the basis for civil time today. This 24-hour time standard is kept using highly precise atomic clocks combined with the Earth's rotation. --> source here

[toddstoker]

@Avidproducers

Are you saying this SDK converting wrong? If so what version number are you seeing this in?

On the other hand I am pretty sure this is not a bug as it should be set to UTC on purpose. UTC is the time standard commonly used across the world. Coordinated Universal Time (UTC) is the basis for civil time today. This 24-hour time standard is kept using highly precise atomic clocks combined with the Earth's rotation. --> source here

The SDK is converting wrong. The API returns a date time string that represents an American Eastern TZ, but the SDK news up a DateTime object as if that string represented a UTC time. This results in a DateTime object that represents the wrong time... It's been a couple of months since I last looked at this so I'd have to dig in again, but I believe this happens in fxmlrpc.

You are spot on with regards to date time handling. The communication/manipulation should absolutely happen in UTC. Unfortunately the API and SDK don't appear to be playing nice together at the moment.

[austinbiggs]

Has this been resolved? We're looking at implementing this SDK and this would definitely affect our end goal.

[toddstoker]

TLDR: The SDK isn't broken. It is correctly parsing the XML returned by the XMLRPC endpoint. Infusionsoft currently handles DateTimes in a strange way.

Upon further investigation, it looks like the XMLRPC endpoint returns the following for DateTimes:

20171030T15:15:00 I'm unfamiliar with ISO 8601, but it would seem that this result _should_ be interpreted as UTC. Recent communication with the API/platform team at Infusionsoft has revealed that custom DateTimes in Infusionsoft are actually TZ-free and don't represent any actual point in time that can be determined without user input. Infusionsoft app TZ can be configured in two (independent) ways: 1. An app-wide setting. 2. A contact-specific setting. DateTime fields on the contact receive no offset from either selected TZ configuration option. Instead when one of these DateTimes is used (like in a sequence field timer), Infusionsoft simply treats the value in the DateTime field as if it represented a DateTime in whichever TZ the user has selected for that particular situation (i.e. in the sequence field timer).

[KelseySheely]

@toddstoker I think that is partially correct, but there are a few things that we have noticed that make this a little more nuanced:

GET Requests

• The xmlrpc API will return dates as is w/out a timezone as you described for CUSTOM FIELDS, but for INTERNAL FIELDS, it will return in Eastern Time, no matter what your app's TZ is.

• The REST API will return INTERNAL DATES in UTC, but will assume CUSTOM FIELDS are in Eastern Time and then convert it to UTC, no matter what your app's TZ is.

POST/PUT Requests

• For adding/updating dates using basic database add/update calls (DataService.update, ContactService.add, etc), the SDK does not read the TZ and inserts directly to the field as the formatted string ($datetime->format("Y-m-d H:i:s"). NOTE: This may only apply to CUSTOM FIELDS as I don't think any INTERNAL FIELDS are writable with these methods.

• For sending in dates to pre-set API Endpoints that expect a date field (ie. InvoiceService.createBlankOrder, InvoiceService.addPaymentPlan), the SDK will read the date as UTC, whether the TZ is set or not. I have only tested createBlankOrder and addPaymentPlan, so I'm not sure if this is true for ALL of these types of endpoints.

[RobertCalise]

This still appears to be an issue. For example, I'm retrieving a record from the Job table.

In my application, the date/time of the order is Monday, April 6, 2020 11:26:49 PM and the timezone is America/New_York. That tracks, I manually created the order at 11:26 PM Eastern last night.

However, when working with the value returned by the API, I see:

DateTime @1586215609 {#43 ▼
  date: 2020-04-06 23:26:49.0 UTC (+00:00)
}

Essentially, it's returning an object that is instantiated in UTC, but the time returned actually corresponds to America/New_York.

Obviously, I can write code to create a new DateTime object with the correct timezone to work around this, but it doesn't make sense to me for the API to behave this way.