Talk:Convert seconds to compound duration: Difference between revisions
Talk:Convert seconds to compound duration (view source)
Revision as of 01:30, 26 February 2020
, 4 years ago→possible optional or extra credit
m (→possible optional or extra credit: added a line sep.) |
|||
| (5 intermediate revisions by 2 users not shown) | |||
Line 39:
:::* years (and centuries) might be something of a problem because the relation between weeks and years is not simple. But it would be doable if the task defined a year as (for example) 52.1786 weeks. The numbers would be a bit nonsensical, but the other option would be be that you have to specify the starting second. And if you are going to do that you might as well do months as well (but this of course changes the task into something very different - see also [[Talk:Holidays_related_to_Easter]] and [[Talk:Last_Friday_of_each_month]] for some of the issues which might be relevant for that kind of a task.
:::* Negative seconds might also change the task, if you wanted to go there. --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 19:35, 20 June 2015 (UTC)
::I'm not really a fan of "extra credit" specs, because they make it more difficult to compare solutions. Though if the admins want them, I suppose "ability to handle fractional seconds" would a suitable candidate. Regarding the other two though:
::* '''0 seconds case:''' I don't see returning an empty string for an input of 0 as problematic, even if the function were meant for practical use. It's logically consistent, and it allows the calling code to use the function like <lang perl6>say compound-duration($seconds) || "now";</lang> in languages where the "or" operator supports passing values through. Because only the calling code knows what is best printed in the 0 case - e.g. if the duration is meant to represent a countdown, it may want to print "now"; in other cases "none"; in other cases "0 sec". OTOH doing it this way may not make sense at all in some languages or contexts, which is IMO an indicator that the task should not mandate it either way.
::* '''higher time units:''' What would be the point? AFAICT, it would just be more of the same and not add anything new/interesting to the solutions - just make them longer and thus less convenient to read/compare. Of course if you mean using actual ''calendar'' months and years (i.e. handling days in month / leap years / leap seconds), that's out of the scope of what this task is meant to show (decomposing a number into a sum of unit quantities). There are other tasks for calendar math.
::--[[User:Smls|Smls]] ([[User talk:Smls|talk]]) 11:35, 30 June 2015 (UTC)
-----
Line 65 ⟶ 70:
Yuppers. 174 time units. Who'd thunk it? -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 20:58, 20 June 2015 (UTC)
:That's awesome! --[[User:Simple9371|Simple9371]] ([[User talk:Simple9371|talk]]) 11:31, 1 July 2015 (UTC)
== Adding variants (Applescript addition) ==
Usual practice, FWIW, is to preserve the posting order, adding new variants below existing ones. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 01:30, 26 February 2020 (UTC)
| |||