https://bugs.gpodder.org/show_bug.cgi?id=1366

--- Comment #2 from Dov Feldstern <[email protected]> 2011-06-29 09:29:52 BST 
---
Hmmm, yes, I see your point...

So how about some combinations of the following ideas (again, I'm not sure I
like these suggestions much myself, just thinking out loud):

(a) json document will return actions which are no more than X into the future
(where X can be configured, X=24h probably makes sense in terms of balancing
timezone-issues tolerance vs. not creating too much noise in terms of the
concerns you've raised).

(b) The web view will mark in red (or whatever) events which are *more* than X
into the future (and thus would not be returned by the json calls); this is
just in order to make it less confusing when trying to debug these issues, and
could alert users/developers to bugs in the clients. Perhaps it would even make
sense to have two different markings --- one for those which are in the future,
but less than X, and one for those which are more than X.

(c) Do we have any sense of how prevalent this issue is -- i.e., how many
actions are really uploaded with future dates? Is it possible to query the
database and find out how many events are *currently* future? How about actions
which had a future timestamp *when they were uploaded*? Is it possible to tell
which client uploaded the actions? If this information is available, that would
be another way (besides rejecting the upload, as originally suggested in option
(3)) of finding client bugs and fixing them.

Ultimately, I still think that the best solution is to not accept the upload of
future actions (option 3 in the original post), (c) could give us an idea of
how much trouble that would cause for users using existing, unpatched, clients.

-- 
Configure bugmail: https://bugs.gpodder.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
gPodder-Bugs mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/gpodder-bugs

Reply via email to