Provide Vendor's current/next available date ranges, distinguish from their inventory refresh dates

[aetaric]

The following is an example from last week's Xur data returned from the vendors endpoint.
{ "vendorHash": 2190858386, "nextRefreshDate": "2017-12-22T09:00:00Z", "enabled": true, "canPurchase": false }
This clearly lists nextRefreshDate as UTC (denoted by the Z at the end of the string) yet it's in GMT-08:00 (PST). The string should read "2017-12-22T09:00:00-08:00". Without this change developers must modify your DateTime strings to the proper timezone before parsing them into a DateTime object in their language. If a new developer to the Bungie API isn't aware of this, it will leave them up to several hours off on DateTime comparisons.

[floatingatoll]

I strongly encourage fixing this in a way that maintains the Z (utc) marking here, as otherwise you'll have to switch correctly from -08:00 to -07:00 and back depending on daylight savings, which mandates a lot of "local system timezone library" requirements on the API server that are best avoided by simply marking it as the correct UTC time for reset.

…

On Sat, Dec 23, 2017 at 5:21 PM, Dustin Essington ***@***.***> wrote: The following is an example from last week's Xur data returned from the vendors endpoint. { "vendorHash": 2190858386, "nextRefreshDate": "2017-12-22T09:00:00Z", "enabled": true, "canPurchase": false } This clearly lists nextRefreshDate as UTC (denoted by the Z at the end of the string) yet it's in GMT-08:00 (PST). The string should read "2017-12-22T09:00:00-08:00". Without this change developers must modify your DateTime strings to the proper timezone before parsing them into a DateTime object in their language. If a new developer to the Bungie API isn't aware of this, it will leave them up to several hours off on DateTime comparisons. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#353>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFqDB14hEwhBuJCT9ImCMBzTeQSELR9ks5tDacEgaJpZM4RLzhn> .

[floatingatoll]

Per https://www.bungie.net/en/Help/Article/46165 reset is at 17:00:00Z each week regardless of daylight savings. On Sat, Dec 23, 2017 at 5:33 PM, Richard Soderberg <rsoderberg@gmail.com> wrote:

…

I strongly encourage fixing this in a way that maintains the Z (utc) marking here, as otherwise you'll have to switch correctly from -08:00 to -07:00 and back depending on daylight savings, which mandates a lot of "local system timezone library" requirements on the API server that are best avoided by simply marking it as the correct UTC time for reset. On Sat, Dec 23, 2017 at 5:21 PM, Dustin Essington < ***@***.***> wrote: > The following is an example from last week's Xur data returned from the > vendors endpoint. > { "vendorHash": 2190858386, "nextRefreshDate": "2017-12-22T09:00:00Z", > "enabled": true, "canPurchase": false } > This clearly lists nextRefreshDate as UTC (denoted by the Z at the end of > the string) yet it's in GMT-08:00 (PST). The string should read > "2017-12-22T09:00:00-08:00". Without this change developers must modify > your DateTime strings to the proper timezone before parsing them into a > DateTime object in their language. If a new developer to the Bungie API > isn't aware of this, it will leave them up to several hours off on DateTime > comparisons. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#353>, or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAFqDB14hEwhBuJCT9ImCMBzTeQSELR9ks5tDacEgaJpZM4RLzhn> > . >

[floatingatoll]

Technically, if you wanted to add a new property alongside nextRefreshDate, "isoRefreshDefinition": "R/2017-W49-2T17:00:00Z/P1W" defines a recurring 1-week duration starting in 2017 week 49 at 17:00Z and repeating thereafter forever. This is incredibly obtuse ISO8601, and probably is of no benefit whatsoever to anyone, but I love ISO8601, so posting it here all the same. On Sat, Dec 23, 2017 at 5:34 PM, Richard Soderberg <rsoderberg@gmail.com> wrote:

…

Per https://www.bungie.net/en/Help/Article/46165 reset is at 17:00:00Z each week regardless of daylight savings. On Sat, Dec 23, 2017 at 5:33 PM, Richard Soderberg ***@***.***> wrote: > I strongly encourage fixing this in a way that maintains the Z (utc) > marking here, as otherwise you'll have to switch correctly from -08:00 to > -07:00 and back depending on daylight savings, which mandates a lot of > "local system timezone library" requirements on the API server that are > best avoided by simply marking it as the correct UTC time for reset. > > On Sat, Dec 23, 2017 at 5:21 PM, Dustin Essington < > ***@***.***> wrote: > >> The following is an example from last week's Xur data returned from the >> vendors endpoint. >> { "vendorHash": 2190858386, "nextRefreshDate": "2017-12-22T09:00:00Z", >> "enabled": true, "canPurchase": false } >> This clearly lists nextRefreshDate as UTC (denoted by the Z at the end >> of the string) yet it's in GMT-08:00 (PST). The string should read >> "2017-12-22T09:00:00-08:00". Without this change developers must modify >> your DateTime strings to the proper timezone before parsing them into a >> DateTime object in their language. If a new developer to the Bungie API >> isn't aware of this, it will leave them up to several hours off on DateTime >> comparisons. >> >> — >> You are receiving this because you are subscribed to this thread. >> Reply to this email directly, view it on GitHub >> <#353>, or mute the thread >> <https://github.com/notifications/unsubscribe-auth/AAFqDB14hEwhBuJCT9ImCMBzTeQSELR9ks5tDacEgaJpZM4RLzhn> >> . >> > >

[aetaric]

Valid UTC time would be fine. ISO8601 with recurring would probably work as well, or just continuing to use the current ISO8601 compatible format in proper UTC would work as well.

[aetaric]

Current workaround I'm doing for this is to do string substitution on the nextRefreshDate changing Z to -08:00 before parsing it to a DateTime object. Most, if not all, languages should be able to handle this, but it shouldn't be on the application side in the long run.

[vthornheart-bng]

I'll have to look into this! All of our times should be returned in UTC, so we will always end up with the "z" designation at the end of the date rather than a time offset. We've got no desire to return any dates other than UTC, as doing so simplifies the use case for many (most? all?) clients.

My suspicion is that this problem is limited to the Vendor endpoint, but I will investigate! Thanks for reporting it!

[vthornheart-bng]

Ah, not fun - I just did some investigating, and I found what's going on.

Turns out the "refresh date" and the rotation of when the Vendor is visible are two different values these days. What you're seeing is the date - properly in UTC, but not showing something necessarily useful in this case - that the Vendor switches from what they used to have for sale to whatever they now have for sale. In the case of Xur, this actually is happening at 9:00 UTC: but Xur isn't actually visible until 17:00 UTC, so this rotation date is essentially useless (and misleading!) for him. For other vendors, this is potentially useful and interesting information: specifically for vendors that are visible all the time, but whose inventory rotates periodically.

I will have to look into what I can provide. I may be able to return the date that the vendor will next be visible in situations where we can calculate it. I'm going to update the title of the bug accordingly, so I don't lose sight of what I'd like to add to the Vendor data.

[vthornheart-bng]

For the time being, I'm adding the following documentation to the nextRefreshDate field for the next time we do a documentation update. Glad you reported this, thanks and keep it coming as you find things!

---

The date when this vendor's inventory will next rotate/refresh.

Note that this is distinct from the date ranges that the vendor is visible/available in-game: this field indicates the specific time when the vendor's available items refresh and rotate, regardless of whether the vendor is actually available at that time. Unfortunately, these two values may be (and are, for the case of important vendors like Xur) different.

Issue #353 is tracking a fix to start providing visibility date ranges where possible in addition to this refresh date, so that all important dates for vendors are available for use.