Document the possibility to specify duration directly

[ohadschn]

It's a really handy feature we discussed on the BitBucket issue tracker. It doesn't look like it's documented anywhere. The BitBucket repo is gone, but I'll dump what I have from the notification e-mails (I can forward them to you formatted properly if you give me your email address):

Stephen McKamey commented on issue #16:Add an API for specifying duration directlyThis is definitely possible and consistent with the purpose of countdown.js. One complication is that countdownjs's "secret sauce" is in that it has an anchoring start or end date. This helps interpret the duration of time when it is ambiguous. For example, 28 days might be "1 month" when the anchoring date is in February, but if it were in December then it would be "4 weeks". 30 days in February would display "1 month and 2 days" unless it was a leap year and then it would return "1 month and 1 day". In November 30 days would be "1 month" but in December it would be "4 weeks and 2 days".In other words, context is important when representing durations of time. This usually comes down to the fact that human months are a pretty broken concept.Taking your example, you have implicitly anchored it to "now". In the case of hours or minutes, it will probably always return the same value. But if you added 2430hours, you might see the result change as the anchoring date changed.But your feature request is still valid. Here's my API proposal: allow countdown(...) to take mock timespan objects as either the start or end arguments. I'm still noodling on what that would look like but here is a possibility:countdown( null, // now { "hours": 48 }, countdown.ALL).toString(); This would format the duration of "48 hours from now". I think the interpretation would need to be that it takes the other date (substituting new Date() for null) and modifies it by the given timespan. On subsequent iterations (e.g., if the other "date" is the callback function) it doesn't change the end date but would continue to count down to it. So this would be similar to what you were showing without having to create a Date and run the helper function. The important thing to remember is that the resulting end (or start) date would be generated from the mock timespan once not on every iteration. I think this is important otherwise it would remain a fixed time interval which would be less useful.Thoughts?View this issue or add a comment by replying to this email.Unwatch this issue to stop receiving email updates. Stephen McKamey commented on issue #16:Add an API for specifying duration directlyThis is definitely possible and consistent with the purpose of countdown.js. One complication is that countdownjs's "secret sauce" is in that it has an anchoring start or end date. This helps interpret the duration of time when it is ambiguous. For example, 28 days might be "1 month" when the anchoring date is in February, but if it were in December then it would be "4 weeks". 30 days in February would display "1 month and 2 days" unless it was a leap year and then it would return "1 month and 1 day". In November 30 days would be "1 month" but in December it would be "4 weeks and 2 days".In other words, context is important when representing durations of time. This usually comes down to the fact that human months are a pretty broken concept.Taking your example, you have implicitly anchored it to "now". In the case of hours or minutes, it will probably always return the same value. But if you added 2430hours, you might see the result change as the anchoring date changed.But your feature request is still valid. Here's my API proposal: allow countdown(...) to take mock timespan objects as either the start or end arguments. I'm still noodling on what that would look like but here is a possibility:countdown( null, // now { "hours": 48 }, countdown.ALL).toString(); This would format the duration of "48 hours from now". I think the interpretation would need to be that it takes the other date (substituting new Date() for null) and modifies it by the given timespan. On subsequent iterations (e.g., if the other "date" is the callback function) it doesn't change the end date but would continue to count down to it. So this would be similar to what you were showing without having to create a Date and run the helper function. The important thing to remember is that the resulting end (or start) date would be generated from the mock timespan once not on every iteration. I think this is important otherwise it would remain a fixed time interval which would be less useful.Thoughts?View this issue or add a comment by replying to this email. Stephen McKamey commented on issue #16:Add an API for specifying duration directlyThis is definitely possible and consistent with the purpose of countdown.js. One complication is that countdownjs's "secret sauce" is in that it has an anchoring start or end date. This helps interpret the duration of time when it is ambiguous. For example, 28 days might be "1 month" when the anchoring date is in February, but if it were in December then it would be "4 weeks". 30 days in February would display "1 month and 2 days" unless it was a leap year and then it would return "1 month and 1 day". In November 30 days would be "1 month" but in December it would be "4 weeks and 2 days".In other words, context is important when representing durations of time. This usually comes down to the fact that human months are a pretty broken concept.Taking your example, you have implicitly anchored it to "now". In the case of hours or minutes, it will probably always return the same value. But if you added 2430hours, you might see the result change as the anchoring date changed.But your feature request is still valid. Here's my API proposal: allow countdown(...) to take mock timespan objects as either the start or end arguments. I'm still noodling on what that would look like but here is a possibility:countdown( null, // now { "hours": 48 }, countdown.ALL).toString(); This would format the duration of "48 hours from now". I think the interpretation would need to be that it takes the other date (substituting new Date() for null) and modifies it by the given timespan. On subsequent iterations (e.g., if the other "date" is the callback function) it doesn't change the end date but would continue to count down to it. So this would be similar to what you were showing without having to create a Date and run the helper function. The important thing to remember is that the resulting end (or start) date would be generated from the mock timespan once not on every iteration. I think this is important otherwise it would remain a fixed time interval which would be less useful.Thoughts? Stephen McKamey commented on issue #16:Add an API for specifying duration directlyThis is definitely possible and consistent with the purpose of countdown.js. One complication is that countdownjs's "secret sauce" is in that it has an anchoring start or end date. This helps interpret the duration of time when it is ambiguous. For example, 28 days might be "1 month" when the anchoring date is in February, but if it were in December then it would be "4 weeks". 30 days in February would display "1 month and 2 days" unless it was a leap year and then it would return "1 month and 1 day". In November 30 days would be "1 month" but in December it would be "4 weeks and 2 days".In other words, context is important when representing durations of time. This usually comes down to the fact that human months are a pretty broken concept.Taking your example, you have implicitly anchored it to "now". In the case of hours or minutes, it will probably always return the same value. But if you added 2430hours, you might see the result change as the anchoring date changed.But your feature request is still valid. Here's my API proposal: allow countdown(...) to take mock timespan objects as either the start or end arguments. I'm still noodling on what that would look like but here is a possibility:countdown( null, // now { "hours": 48 }, countdown.ALL).toString(); This would format the duration of "48 hours from now". I think the interpretation would need to be that it takes the other date (substituting new Date() for null) and modifies it by the given timespan. On subsequent iterations (e.g., if the other "date" is the callback function) it doesn't change the end date but would continue to count down to it. So this would be similar to what you were showing without having to create a Date and run the helper function. The important thing to remember is that the resulting end (or start) date would be generated from the mock timespan once not on every iteration. I think this is important otherwise it would remain a fixed time interval which would be less useful.Thoughts? Stephen McKamey commented on issue #16: Add an API for specifying duration directly This is definitely possible and consistent with the purpose of countdown.js. One complication is that countdownjs's "secret sauce" is in that it has an anchoring start or end date. This helps interpret the duration of time when it is ambiguous. For example, 28 days might be "1 month" when the anchoring date is in February, but if it were in December then it would be "4 weeks". 30 days in February would display "1 month and 2 days" unless it was a leap year and then it would return "1 month and 1 day". In November 30 days would be "1 month" but in December it would be "4 weeks and 2 days".In other words, context is important when representing durations of time. This usually comes down to the fact that human months are a pretty broken concept.Taking your example, you have implicitly anchored it to "now". In the case of hours or minutes, it will probably always return the same value. But if you added 24*30hours, you might see the result change as the anchoring date changed.But your feature request is still valid. Here's my API proposal: allow countdown(...) to take mock timespan objects as either the start or end arguments. I'm still noodling on what that would look like but here is a possibility:countdown( null, // now { "hours": 48 }, countdown.ALL).toString(); This would format the duration of "48 hours from now". I think the interpretation would need to be that it takes the other date (substituting new Date() for null) and modifies it by the given timespan. On subsequent iterations (e.g., if the other "date" is the callback function) it doesn't change the end date but would continue to count down to it. So this would be similar to what you were showing without having to create a Date and run the helper function. The important thing to remember is that the resulting end (or start) date would be generated from the mock timespan once not on every iteration. I think this is important otherwise it would remain a fixed time interval which would be less useful.Thoughts?     View this issue or add a comment by replying to this email. Unwatch this issue to stop receiving email updates. Unwatch this issue to stop receiving email updates.    

---

Stephen McKamey commented on issue #16:Add an API for specifying duration directlyThis is definitely possible and consistent with the purpose of countdown.js. One complication is that countdownjs's "secret sauce" is in that it has an anchoring start or end date. This helps interpret the duration of time when it is ambiguous. For example, 28 days might be "1 month" when the anchoring date is in February, but if it were in December then it would be "4 weeks". 30 days in February would display "1 month and 2 days" unless it was a leap year and then it would return "1 month and 1 day". In November 30 days would be "1 month" but in December it would be "4 weeks and 2 days".In other words, context is important when representing durations of time. This usually comes down to the fact that human months are a pretty broken concept.Taking your example, you have implicitly anchored it to "now". In the case of hours or minutes, it will probably always return the same value. But if you added 2430hours, you might see the result change as the anchoring date changed.But your feature request is still valid. Here's my API proposal: allow countdown(...) to take mock timespan objects as either the start or end arguments. I'm still noodling on what that would look like but here is a possibility:countdown( null, // now { "hours": 48 }, countdown.ALL).toString(); This would format the duration of "48 hours from now". I think the interpretation would need to be that it takes the other date (substituting new Date() for null) and modifies it by the given timespan. On subsequent iterations (e.g., if the other "date" is the callback function) it doesn't change the end date but would continue to count down to it. So this would be similar to what you were showing without having to create a Date and run the helper function. The important thing to remember is that the resulting end (or start) date would be generated from the mock timespan once not on every iteration. I think this is important otherwise it would remain a fixed time interval which would be less useful.Thoughts?View this issue or add a comment by replying to this email. Stephen McKamey commented on issue #16:Add an API for specifying duration directlyThis is definitely possible and consistent with the purpose of countdown.js. One complication is that countdownjs's "secret sauce" is in that it has an anchoring start or end date. This helps interpret the duration of time when it is ambiguous. For example, 28 days might be "1 month" when the anchoring date is in February, but if it were in December then it would be "4 weeks". 30 days in February would display "1 month and 2 days" unless it was a leap year and then it would return "1 month and 1 day". In November 30 days would be "1 month" but in December it would be "4 weeks and 2 days".In other words, context is important when representing durations of time. This usually comes down to the fact that human months are a pretty broken concept.Taking your example, you have implicitly anchored it to "now". In the case of hours or minutes, it will probably always return the same value. But if you added 2430hours, you might see the result change as the anchoring date changed.But your feature request is still valid. Here's my API proposal: allow countdown(...) to take mock timespan objects as either the start or end arguments. I'm still noodling on what that would look like but here is a possibility:countdown( null, // now { "hours": 48 }, countdown.ALL).toString(); This would format the duration of "48 hours from now". I think the interpretation would need to be that it takes the other date (substituting new Date() for null) and modifies it by the given timespan. On subsequent iterations (e.g., if the other "date" is the callback function) it doesn't change the end date but would continue to count down to it. So this would be similar to what you were showing without having to create a Date and run the helper function. The important thing to remember is that the resulting end (or start) date would be generated from the mock timespan once not on every iteration. I think this is important otherwise it would remain a fixed time interval which would be less useful.Thoughts? Stephen McKamey commented on issue #16:Add an API for specifying duration directlyThis is definitely possible and consistent with the purpose of countdown.js. One complication is that countdownjs's "secret sauce" is in that it has an anchoring start or end date. This helps interpret the duration of time when it is ambiguous. For example, 28 days might be "1 month" when the anchoring date is in February, but if it were in December then it would be "4 weeks". 30 days in February would display "1 month and 2 days" unless it was a leap year and then it would return "1 month and 1 day". In November 30 days would be "1 month" but in December it would be "4 weeks and 2 days".In other words, context is important when representing durations of time. This usually comes down to the fact that human months are a pretty broken concept.Taking your example, you have implicitly anchored it to "now". In the case of hours or minutes, it will probably always return the same value. But if you added 2430hours, you might see the result change as the anchoring date changed.But your feature request is still valid. Here's my API proposal: allow countdown(...) to take mock timespan objects as either the start or end arguments. I'm still noodling on what that would look like but here is a possibility:countdown( null, // now { "hours": 48 }, countdown.ALL).toString(); This would format the duration of "48 hours from now". I think the interpretation would need to be that it takes the other date (substituting new Date() for null) and modifies it by the given timespan. On subsequent iterations (e.g., if the other "date" is the callback function) it doesn't change the end date but would continue to count down to it. So this would be similar to what you were showing without having to create a Date and run the helper function. The important thing to remember is that the resulting end (or start) date would be generated from the mock timespan once not on every iteration. I think this is important otherwise it would remain a fixed time interval which would be less useful.Thoughts? Stephen McKamey commented on issue #16: Add an API for specifying duration directly This is definitely possible and consistent with the purpose of countdown.js. One complication is that countdownjs's "secret sauce" is in that it has an anchoring start or end date. This helps interpret the duration of time when it is ambiguous. For example, 28 days might be "1 month" when the anchoring date is in February, but if it were in December then it would be "4 weeks". 30 days in February would display "1 month and 2 days" unless it was a leap year and then it would return "1 month and 1 day". In November 30 days would be "1 month" but in December it would be "4 weeks and 2 days".In other words, context is important when representing durations of time. This usually comes down to the fact that human months are a pretty broken concept.Taking your example, you have implicitly anchored it to "now". In the case of hours or minutes, it will probably always return the same value. But if you added 2430hours, you might see the result change as the anchoring date changed.But your feature request is still valid. Here's my API proposal: allow countdown(...) to take mock timespan objects as either the start or end arguments. I'm still noodling on what that would look like but here is a possibility:countdown( null, // now { "hours": 48 }, countdown.ALL).toString(); This would format the duration of "48 hours from now". I think the interpretation would need to be that it takes the other date (substituting new Date() for null) and modifies it by the given timespan. On subsequent iterations (e.g., if the other "date" is the callback function) it doesn't change the end date but would continue to count down to it. So this would be similar to what you were showing without having to create a Date and run the helper function. The important thing to remember is that the resulting end (or start) date would be generated from the mock timespan once not on every iteration. I think this is important otherwise it would remain a fixed time interval which would be less useful.Thoughts?     View this issue or add a comment by replying to this email.
Stephen McKamey commented on issue #16:Add an API for specifying duration directlyThis is definitely possible and consistent with the purpose of countdown.js. One complication is that countdownjs's "secret sauce" is in that it has an anchoring start or end date. This helps interpret the duration of time when it is ambiguous. For example, 28 days might be "1 month" when the anchoring date is in February, but if it were in December then it would be "4 weeks". 30 days in February would display "1 month and 2 days" unless it was a leap year and then it would return "1 month and 1 day". In November 30 days would be "1 month" but in December it would be "4 weeks and 2 days".In other words, context is important when representing durations of time. This usually comes down to the fact that human months are a pretty broken concept.Taking your example, you have implicitly anchored it to "now". In the case of hours or minutes, it will probably always return the same value. But if you added 2430hours, you might see the result change as the anchoring date changed.But your feature request is still valid. Here's my API proposal: allow countdown(...) to take mock timespan objects as either the start or end arguments. I'm still noodling on what that would look like but here is a possibility:countdown( null, // now { "hours": 48 }, countdown.ALL).toString(); This would format the duration of "48 hours from now". I think the interpretation would need to be that it takes the other date (substituting new Date() for null) and modifies it by the given timespan. On subsequent iterations (e.g., if the other "date" is the callback function) it doesn't change the end date but would continue to count down to it. So this would be similar to what you were showing without having to create a Date and run the helper function. The important thing to remember is that the resulting end (or start) date would be generated from the mock timespan once not on every iteration. I think this is important otherwise it would remain a fixed time interval which would be less useful.Thoughts? Stephen McKamey commented on issue #16:Add an API for specifying duration directlyThis is definitely possible and consistent with the purpose of countdown.js. One complication is that countdownjs's "secret sauce" is in that it has an anchoring start or end date. This helps interpret the duration of time when it is ambiguous. For example, 28 days might be "1 month" when the anchoring date is in February, but if it were in December then it would be "4 weeks". 30 days in February would display "1 month and 2 days" unless it was a leap year and then it would return "1 month and 1 day". In November 30 days would be "1 month" but in December it would be "4 weeks and 2 days".In other words, context is important when representing durations of time. This usually comes down to the fact that human months are a pretty broken concept.Taking your example, you have implicitly anchored it to "now". In the case of hours or minutes, it will probably always return the same value. But if you added 2430hours, you might see the result change as the anchoring date changed.But your feature request is still valid. Here's my API proposal: allow countdown(...) to take mock timespan objects as either the start or end arguments. I'm still noodling on what that would look like but here is a possibility:countdown( null, // now { "hours": 48 }, countdown.ALL).toString(); This would format the duration of "48 hours from now". I think the interpretation would need to be that it takes the other date (substituting new Date() for null) and modifies it by the given timespan. On subsequent iterations (e.g., if the other "date" is the callback function) it doesn't change the end date but would continue to count down to it. So this would be similar to what you were showing without having to create a Date and run the helper function. The important thing to remember is that the resulting end (or start) date would be generated from the mock timespan once not on every iteration. I think this is important otherwise it would remain a fixed time interval which would be less useful.Thoughts? Stephen McKamey commented on issue #16: Add an API for specifying duration directly This is definitely possible and consistent with the purpose of countdown.js. One complication is that countdownjs's "secret sauce" is in that it has an anchoring start or end date. This helps interpret the duration of time when it is ambiguous. For example, 28 days might be "1 month" when the anchoring date is in February, but if it were in December then it would be "4 weeks". 30 days in February would display "1 month and 2 days" unless it was a leap year and then it would return "1 month and 1 day". In November 30 days would be "1 month" but in December it would be "4 weeks and 2 days".In other words, context is important when representing durations of time. This usually comes down to the fact that human months are a pretty broken concept.Taking your example, you have implicitly anchored it to "now". In the case of hours or minutes, it will probably always return the same value. But if you added 2430hours, you might see the result change as the anchoring date changed.But your feature request is still valid. Here's my API proposal: allow countdown(...) to take mock timespan objects as either the start or end arguments. I'm still noodling on what that would look like but here is a possibility:countdown( null, // now { "hours": 48 }, countdown.ALL).toString(); This would format the duration of "48 hours from now". I think the interpretation would need to be that it takes the other date (substituting new Date() for null) and modifies it by the given timespan. On subsequent iterations (e.g., if the other "date" is the callback function) it doesn't change the end date but would continue to count down to it. So this would be similar to what you were showing without having to create a Date and run the helper function. The important thing to remember is that the resulting end (or start) date would be generated from the mock timespan once not on every iteration. I think this is important otherwise it would remain a fixed time interval which would be less useful.Thoughts?    
Stephen McKamey commented on issue #16:Add an API for specifying duration directlyThis is definitely possible and consistent with the purpose of countdown.js. One complication is that countdownjs's "secret sauce" is in that it has an anchoring start or end date. This helps interpret the duration of time when it is ambiguous. For example, 28 days might be "1 month" when the anchoring date is in February, but if it were in December then it would be "4 weeks". 30 days in February would display "1 month and 2 days" unless it was a leap year and then it would return "1 month and 1 day". In November 30 days would be "1 month" but in December it would be "4 weeks and 2 days".In other words, context is important when representing durations of time. This usually comes down to the fact that human months are a pretty broken concept.Taking your example, you have implicitly anchored it to "now". In the case of hours or minutes, it will probably always return the same value. But if you added 2430hours, you might see the result change as the anchoring date changed.But your feature request is still valid. Here's my API proposal: allow countdown(...) to take mock timespan objects as either the start or end arguments. I'm still noodling on what that would look like but here is a possibility:countdown( null, // now { "hours": 48 }, countdown.ALL).toString(); This would format the duration of "48 hours from now". I think the interpretation would need to be that it takes the other date (substituting new Date() for null) and modifies it by the given timespan. On subsequent iterations (e.g., if the other "date" is the callback function) it doesn't change the end date but would continue to count down to it. So this would be similar to what you were showing without having to create a Date and run the helper function. The important thing to remember is that the resulting end (or start) date would be generated from the mock timespan once not on every iteration. I think this is important otherwise it would remain a fixed time interval which would be less useful.Thoughts? Stephen McKamey commented on issue #16: Add an API for specifying duration directly This is definitely possible and consistent with the purpose of countdown.js. One complication is that countdownjs's "secret sauce" is in that it has an anchoring start or end date. This helps interpret the duration of time when it is ambiguous. For example, 28 days might be "1 month" when the anchoring date is in February, but if it were in December then it would be "4 weeks". 30 days in February would display "1 month and 2 days" unless it was a leap year and then it would return "1 month and 1 day". In November 30 days would be "1 month" but in December it would be "4 weeks and 2 days".In other words, context is important when representing durations of time. This usually comes down to the fact that human months are a pretty broken concept.Taking your example, you have implicitly anchored it to "now". In the case of hours or minutes, it will probably always return the same value. But if you added 2430hours, you might see the result change as the anchoring date changed.But your feature request is still valid. Here's my API proposal: allow countdown(...) to take mock timespan objects as either the start or end arguments. I'm still noodling on what that would look like but here is a possibility:countdown( null, // now { "hours": 48 }, countdown.ALL).toString(); This would format the duration of "48 hours from now". I think the interpretation would need to be that it takes the other date (substituting new Date() for null) and modifies it by the given timespan. On subsequent iterations (e.g., if the other "date" is the callback function) it doesn't change the end date but would continue to count down to it. So this would be similar to what you were showing without having to create a Date and run the helper function. The important thing to remember is that the resulting end (or start) date would be generated from the mock timespan once not on every iteration. I think this is important otherwise it would remain a fixed time interval which would be less useful.Thoughts?    
Stephen McKamey commented on issue #16:
Add an API for specifying duration directly
This is definitely possible and consistent with the purpose of countdown.js. One complication is that countdownjs's "secret sauce" is in that it has an anchoring start or end date. This helps interpret the duration of time when it is ambiguous. For example, 28 days might be "1 month" when the anchoring date is in February, but if it were in December then it would be "4 weeks". 30 days in February would display "1 month and 2 days" unless it was a leap year and then it would return "1 month and 1 day". In November 30 days would be "1 month" but in December it would be "4 weeks and 2 days".In other words, context is important when representing durations of time. This usually comes down to the fact that human months are a pretty broken concept.Taking your example, you have implicitly anchored it to "now". In the case of hours or minutes, it will probably always return the same value. But if you added 2430hours, you might see the result change as the anchoring date changed.But your feature request is still valid. Here's my API proposal: allow countdown(...) to take mock timespan objects as either the start or end arguments. I'm still noodling on what that would look like but here is a possibility:countdown( null, // now { "hours": 48 }, countdown.ALL).toString(); This would format the duration of "48 hours from now". I think the interpretation would need to be that it takes the other date (substituting new Date() for null) and modifies it by the given timespan. On subsequent iterations (e.g., if the other "date" is the callback function) it doesn't change the end date but would continue to count down to it. So this would be similar to what you were showing without having to create a Date and run the helper function. The important thing to remember is that the resulting end (or start) date would be generated from the mock timespan once not on every iteration. I think this is important otherwise it would remain a fixed time interval which would be less useful.Thoughts?