Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GetOpeningTimes not returning today's opening time #278

Open
TheConsciousness opened this issue Feb 8, 2020 · 2 comments
Open

GetOpeningTimes not returning today's opening time #278

TheConsciousness opened this issue Feb 8, 2020 · 2 comments

Comments

@TheConsciousness
Copy link

Park
Which park/resort has this issue?
WaltDisneyWorldMagicKingdom

Context

  • themeparks version used: 5.1.33
  • Operating System: Ubuntu 18.04

Describe the bug
Having an issue with getting today's opening time. Also receiving one extra day when using scheduleDaysToReturn.

const DisneyWorldMagicKingdom = new Themeparks.Parks.WaltDisneyWorldMagicKingdom({scheduleDaysToReturn:1}); DisneyWorldMagicKingdom.GetOpeningTimes().then((data) => { console.log(data); });

Output
[ { date: '2020-02-08', openingTime: '2020-02-08T09:00:00-05:00', closingTime: '2020-02-08T22:00:00-05:00', type: 'Operating' }, { date: '2020-02-09', openingTime: '2020-02-09T09:00:00-05:00', closingTime: '2020-02-09T21:00:00-05:00', type: 'Operating' } ]

@cmlara
Copy link
Contributor

cmlara commented Mar 9, 2020

Tested in themeaprks 5.1.34:

Doing some testing I believe the issue with not fetching today is in BuildOpeningTimesResponse() in /lib/park.js

// resolve with our new schedule data
return Promise.resolve(this.Schedule.GetDateRange({
  startDate: Moment(),
  endDate: Moment().add(this[sScheduleDaysToReturn], 'days'),
}));

I believe this should be:

// resolve with our new schedule data
return Promise.resolve(this.Schedule.GetDateRange({
  startDate: Moment().tz(this.Timezone),
  endDate: Moment().add(this[sScheduleDaysToReturn], 'days'),
}));

Specifically the startDate being sent to GetDateRange is being sent in the computer executing the scripts time but for parks when your system is set to a timezone east of the park (such as your system is running UTC time) the call to Moment() can be a "day ahead" of the park in question when the system running the script cross over the 00:00 mark before the park does.

@cmlara
Copy link
Contributor

cmlara commented Mar 9, 2020

Did some additional debugging, While trying to find out why 2 days are returned I believe the endDate line should also be changed to:

Moment().add(this[sScheduleDaysToReturn]-1, 'days').tz(this.Timezone),

To handle both the timezone difference AND to correct what looks being interpreted as instead of "Today to Tomorrow Inclusive" instead of we need it to be "Today to Today inclusive"

BIGGER issue I'm hitting is an edgecase in lib/disney/disneyFacilityChannel.js inside CalendarDocDate()

The edge case is if the first time you pull the schedule for a day (such as if your cache database is just being created) AND your local timezone is a 'day ahead' compared to the Disney Park we end up moving today's schedule a year ahead in the cache database mapping. If we populate the cache database before we are a 'day ahead' (such as running a script for a few days, or pulling early in the day before a date rollover) there is information to pull from the database and everything works.

The key line is
const today = Moment();

Same issue as in the notes before about startDate: Moment() that this is "tomorrow" as it relates to the park if you are in a Timezone ahead of the parks.

Unfortunately this.Timezone and this[sTimzone] are both out of scope inside of disneyFacilityChannel.js.

It seems to me that in order to fix this that a new option needs to be added to the FacilityChannel to pass the value of options.timezone into the Facility so it can store it as a local variable. However perhaps there is an easier method I'm missing in how to pass this through?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants