ParseCron should give relative times about zeroclickinfo-goodies HOT 7 CLOSED

And/or times in the local timezone (I believe this can be figured out from JavaScript, at least when running in the browser and not in the zeroclick API).

from zeroclickinfo-goodies.

I feel that the @_gagan's relative time will still have the same drawback, e.g: if DDG's server time is 12PM and a cron job is run every day at 2PM, the relative result of "After 2 hours" will still be incorrect for users in, say, the DDG+4 timezone (they would expect "After 22 hours" instead).

@Habbie's fix is the best case scenario, but I fear this is beyond my skill. There are a couple of other fixes I do have in mind:

a) Show the time in UTC to eliminate confusion. e.g.
Cron will start this event next at 12:42:00 on 2 Feb, 2013 UTC.

b) Show the next 3 events to make it clearer. e.g.
Cron will start this event next at the following times:
06:01:00 on 15 May, 2012.
06:02:00 on 15 May, 2012.
06:03:00 on 15 May, 2012.
Not the best fix, but this at least clearly shows that the cron job is run per minute, irrespective of timezone.

Any suggestions?

from zeroclickinfo-goodies.

I like option b) a lot as I often want to know a few times it will start. Also we could change the wording a bit to indicate like Cron will schedule this job at this frequency:

from zeroclickinfo-goodies.

+1 for option b

Gabriel Weinberg [email protected] wrote:

I like option b) a lot as I often want to know a few times it will
start. Also we could change the wording a bit to indicate like Cron
will schedule this job at this frequency:

---

Reply to this email directly or view it on GitHub:
#95 (comment)

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

from zeroclickinfo-goodies.

Didn't occur to me relative time would suffer from the same drawback. Javascript will be the perfect solution, but if that's not possible, showing the time/date and linking to WolframAlpha with the query will show better details.

from zeroclickinfo-goodies.

This was fixed, why it wasn't closed yet?

from zeroclickinfo-goodies.

Closing. Looks to have been fixed in a0d1a1f

from zeroclickinfo-goodies.