Some discussion in the forums suggested that setting system clock to UTC or
patching default.py with "utcnow()" to get the current time in UTC would fix
the problem of missing events. However, that doesn't seem to be the case.
Consider the feed returned by this url:
http://espn.go.com/watchespn/feeds/startup?action=replay&channel=espn3&startDate
=20120109&endDate=20120110
It returns only events with a startTime that begins with "20120109". This may
be even more telling:
http://espn.go.com/watchespn/feeds/startup?action=replay&channel=espn3&startDate
=20120110&endDate=20120110
Returns no events, where you might expect it to return all events for Jan.
10th. It appears that to return all of today's replay events, startDate needs
to be today and endDate needs to be tomorrow.
For viewers in most of the U.S. at GMT-5 to GMT-8, utcnow() would return
"tomorrow" during common viewing hours in the evening, and so many wouldn't
notice the issue if they use that patch. Likewise for viewers in Europe/Asia
time zones, the unpatched now() in local time could often be "tomorrow"
relative to ESPN's events feed.
Based on what I can see bouncing the feed request through a few proxies around
the globe, ESPN's feed server doesn't appear to make any correction for local
time of the request origin, reporting and returning all event start times in US
Eastern Time Zone (EST or EDT).
So, for consistent replay results everywhere I think default.py needs to use
something like "utcnow() + timedelta(days=1) - timedelta(hours=5)" for the
endDate used in replay calculations. Or otherwise do something more
sophisticated to get "now" in the U.S. Eastern time zone and then add one day.
The endDate could just be set arbitrarily into the future, but if curdate isn't
now in Eastern, startDate won't be consistent with the configured number of
days of replay events.
Original issue reported on code.google.com by fatcat...@gmail.com on 11 Jan 2012 at 10:04
Original issue reported on code.google.com by
fatcat...@gmail.com
on 11 Jan 2012 at 10:04