Template talk:Countdown

Automatic refresh?

I'm interested to use this on the sister Wikivoyage project.

The values only appear to update whenever the host article using the template is edited.

Is there anyway to have the values refresh at least once a day? Andrewssi2 (talk) 23:17, 1 April 2015 (UTC)

There is nothing you can place in the page source to make it update regularly by itself. A purge will update the page. You could for example place wikivoyage:Template:Purge next to uses. In the English Wikipedia User:Joe's Null Bot is coded to automatically purge some pages regularly. I don't know whether Wikivoyage has bots which can do this or a place to request it. PrimeHunter (talk) 01:53, 2 April 2015 (UTC)

Inappropriate precision

The 'East Coast Belly Dance Cruise' countdown in the template's documentation page is timed from a start date: |year=2016, |month=12, |day=12. Without a start time, it seems to me that countdown hours, minutes, and seconds are unknown and so should not be part of the rendered display.

I have modified a sandbox version of the module so that the display precision is more (I think) appropriate:

{{countdown/sandbox |year=2016 |month=12 |day=12}}

→

{{countdown/sandbox |year=2016 |month=12 |day=12 |hour=12}}

→

{{countdown/sandbox |year=2016 |month=12 |day=12 |hour=12 |minute=30}}

→

{{countdown/sandbox |year=2016 |month=12 |day=12 |hour=12 |minute=30 |second=7}}

→

Server time is: 06:16:21

While this change is also applied to the post-event call to formatMessage(), that section of the code needs additional work because of the undocumented parameters it uses and to make sure it does the right thing when those parameters aren't set in the template.

—Trappist the monk (talk) 15:38, 11 April 2015 (UTC)

• I understand your point, and I still think the precision is appropriate for the last 24 hours. Is there a way we can have the template only include that precision if the largest time span provided results in < 1? For example, if only year and month is provided, then weeks, days, hours shouldn't be rendered until there is < a month left. — {{U|Technical 13}} (e • t • c) 16:07, 11 April 2015 (UTC)

Point. I've tweaked the module so that when there are less than 24 hours remaining, the template displays remaining hours, minutes, and seconds even if a start time is not specified:

{{countdown/sandbox |year={{#time:Y|tomorrow}} |month={{#time:n|tomorrow}} |day={{#time:j|tomorrow}} |hour= |minute= |second=}}

→

I also tweaked the default hours back to zero. os.time() uses 12 hours as the default if |hour= is not specified.

And why doesn't lang:formatDuration () understand 'months' as an output option? How many people measure time in more than a few weeks before shifting to months?

It would seem a good thing to do to support an event timezone parameter so that editors don't have to calculate UTC from some specific local time.

—Trappist the monk (talk) 17:32, 11 April 2015 (UTC)

• I'm guessing as to months that it has to do with inconsistency in the length of a month. There are a few ways to deal with the issue, none of them are perfect and it will be a matter of preference as to which we use. I personally define it as 30.4375 days. I'm a passenger in a vehicle on a 1 hour ride with a nearly dead battery. Will look again once I get home. — {{U|Technical 13}} (e • t • c) 19:09, 11 April 2015 (UTC)

countdown-ymd (ex countdown/sandbox2)

the following discussions refer to what was {{countdown/sandbox2}} and is now {{countdown-ymd/sandbox}}. Further discussion should take place at that template's talk page—Trappist the monk (talk) 15:28, 28 April 2015 (UTC)

Extended content

Yesterday I hacked a version of {{countdown}} that manually calculates the difference between two date-times. Essentially it subtracts current date-time from some future date time: future second - current second = difference second; borrow 60 seconds from future minute if necessary. when the code gets to taking the days difference, if it is necessary to borrow days from future month, borrow the days from the previous future month. So, if future date is 2016 April 1, borrow the 31 days of 2016 March so that in effect, future date becomes 2016 March 32. I think that this code works. In the following examples, the countdowns are listed in live, sandbox, and sandbox2 order. Countdown to tomorrow at 18:00:00 2024-12-25T06:16:21 (UTC) – time this page was last refreshed Target time: 2024-12-26T18:00:00 (UTC) There is 1 day, 11 hours, 43 minutes and 39 seconds until the event begins. (refresh) Time to event: 1 day, 11 hours, 43 minutes, 39 seconds [refresh] Countdown to 2025-06-26 at 18:00:00 2024-12-25T06:16:21 (UTC) – time this page was last refreshed There are 183 days, 11 hours, 43 minutes and 39 seconds until the event begins. (refresh) Time to event: 6 months, 1 day, 11 hours, 43 minutes, 39 seconds [refresh] Countdown to 2025-12-26 at 18:00:00 2024-12-25T06:16:21 (UTC) – time this page was last refreshed There is 1 year, 1 day, 5 hours, 54 minutes and 27 seconds until the event begins. (refresh) Time to event: 1 year, 1 day, 11 hours, 43 minutes, 39 seconds [refresh] Notice the difference in the displayed times. You should be able to add the time this page was last refreshed to the countdown time and arrive at a sum of 18:00:00. I'm beginning to think that maybe there is a problem with os.difftime () or with lang:formatDuration (). The displayed time seems non-nonsensical to me. As you can see, I changed the default text to be less wordy. |color=, and |event= aren't yet supported. I'm not sure what to do about |duration=, |duration unit=, |eventstart=, and |eventend=. —Trappist the monk (talk) 12:55, 13 April 2015 (UTC) I've added |utc offset=. The code doesn't currently validate the input other than to require it to be in the form [+|-]HH:MM (02:00 or +02:00 or -06:00) Current time: 2024-12-25T06:16:21 (UTC) Target time: 2024-12-25T07:00:00 (UTC) {{countdown-ymd/sandbox |year={{#time:Y|now + 1 hour}} |month={{#time:m|now + 1 hour}} |day={{#time:d|now + 1 hour}} |hour={{#time:H|now + 1 hour}} |minute=0 |second=0 |utc offset =}} →Time to event: 43 minutes, 39 seconds [refresh] – |utc offset= Current time: 2024-12-25T00:16:21 (UTC-06:00) Target time: 2024-12-25T01:00:00 (UTC-06:00) {{countdown-ymd/sandbox |year={{#time:Y|now -5 hours}} |month={{#time:m|now -5 hours}} |day={{#time:d|now -5 hours}} |hour={{#time:H|now -5 hours}} |minute=0 |second=0 |utc offset = -06:00}} (now -5 hours spoofs the time parser into providing a target time one hour from now in time zone UTC-06:00) →Time to event: 43 minutes, 39 seconds [refresh] – |utc offset=-6:00 —Trappist the monk (talk) 00:41, 14 April 2015 (UTC) UTC bounds checking, and now supports three flavors of offset: the +HH:MM (all digits, sign, and colon required), -hhMM (sign and colon optional), and hh (sign optional) where hh is one or two digits. If hours greater than 12 or minutes greater than 59, offset is set to UTC±00:00. Time to event: 43 minutes, 39 seconds [refresh] – formal style: |utc offset=-06:00 Time to event: 43 minutes, 39 seconds [refresh] – informal style (with optional colon): |utc offset=-6:00 Time to event: 43 minutes, 39 seconds [refresh] – informal style (without optional colon): |utc offset=-600 Time to event: 43 minutes, 39 seconds [refresh] – informal style: |utc offset=-6 Event time has passed. – minutes out of range: |utc offset=-05:60 Event time has passed. – hours out of range: |utc offset=-13:00 —Trappist the monk (talk) 12:10, 15 April 2015 (UTC) There seems to be some inaccuracies and inconsistencies in some of the examples. It's saying 1 day and 17 hours until tomorrow at 18:00 which should be 17 hours (getting an extra day somehow) and in the example for 2016/04/15 live and sandbox say 1 year 2 days #### and sandbox2 says 1 year 1 day ### which isn't consistent. — {{U|Technical 13}} (e • t • c) 00:55, 14 April 2015 (UTC) For the countdown to 18:00:00 tomorrow I've added a target time using the same {{#time}} parser strings as the template tests. Adding the countdown time to the page-last-refreshed time should give you target time. I don't have any evidence of this, but I think that the apparent discrepancy you see arises in part because of the different units and perhaps in how the templates account for the non-integer number of days in a year. Live and sandbox use weeks. For the simple case of calendar days, 365 days ÷ 7 days per week = 52 weeks remainder 1 day; 52 weeks is one year so that gives us 1 year, 1 day + tomorrow = 1 year, 2 days. For sandbox2, the calculation is done differently. Subtract day from day, borrowing all days from previous month and reducing month by 1 if necessary, subtract month from month, borrowing a month from year and reducing year by 1 if necessary, and finally subtracting year from year. One year from today is this same month and day next year regardless of leapyear, so we have 1 year + tomorrow = 1 year, 1 day. The hours-minutes-seconds time discrepancy likely arises from the same mathematical manipulation used for live and sandbox. If os.difftime () uses a non-integer year length in its calculations then what remains after extracting years, weeks, and days may give incorrect time results. Since all three templates agree regarding hours-minutes-seconds when the date/time difference is less than a year, it seems that this guess is possible. —Trappist the monk (talk) 13:04, 14 April 2015 (UTC) Countdown to 2016-04-15 at 18:00:00 2015-04-14T13:15:29 (UTC) – time this page was last refreshed There is 1 year, 1 day, 22 hours, 55 minutes and 19 seconds until the event begins. (refresh) There is 1 year, 1 day, 22 hours, 55 minutes and 19 seconds until the event begins. (refresh) Event begins in 1 year, 1 day, 4 hours, 44 minutes, 31 seconds (refresh) There can't really be a difference in hours, minutes, and seconds, can there? I'm not saying this is a bad idea (although I could see where it might look like I was trying to make that point), I'm just reporting what I'm seeing and trying to figure out the best way to make this work right. I've worked on many of these time related templates before, and they are always a pain to figure out and get working kinda right and close enough. — {{U|Technical 13}} (e • t • c) 13:22, 14 April 2015 (UTC) This equation should always be true when years, months, weeks, and days are integer multiples of days: page refresh time + countdown time = target time where (using the times from your example): page refresh time = 13:15:29 countdown time = 22:55:19 (live and sandbox) countdown time = 04:44:31 (sandbox2) target time = 18:00:00 live and sandbox: 13:15:29 + 22:55:19 = 36:10:48 sandbox2: 13:15:29 + 04:44:31 = 18:00:00 Right? But what if a year is defined as 365.2425 days? 1460743200 – target time (seconds) 1429017329 – page refresh time (seconds) 31725871 – difference between target time and page refresh time (seconds) 31556952 – 365.2425 * 24 * 60 * 60 (1 year of seconds) 168919 – target time - page refresh time - 1 year (seconds) 82519 – target time - page refresh time - 1 year - 1 day (seconds) 22 remainder 3319 – {{#expr:floor(82519/3600)}} remainder {{#expr:82519-{{#expr:floor(82519/3600)*3600}}}} 55 remainder 19 – {{#expr:floor(3319/60)}} remainder {{#expr:3319-{{#expr:floor(3319/60)*60}}}} So, we have 1 year, 1 day, 22 hours, 55 minutes, 19 seconds. I'm guessing that this is similar to how os.difftime () gets its answer. —Trappist the monk (talk) 15:04, 14 April 2015 (UTC) adjacent text It seems to me that editors should have more flexibility when it comes to the text surrounding the countdown. So I invented some parameters: |lead= – text that precedes the countdown; when set to none inhibits display of the default text |tail= – text that follows the countdown |event lead= – text that precedes the countdown when |duration= is set and event has started; when set to none inhibits display of the default text |event tail= – text that follows the countdown while the event is in progress |expired= – text to display when the event is in the past; when set to none inhibits display of the default text And some examples: This is the lead text: 1 day, 11 hours, 43 minutes, 39 seconds [refresh] Event has ended. This is the expired text. (outside the template: |expired=none in the template) 1 day, 11 hours, 43 minutes, 39 seconds [refresh] (outside the template: |lead=none in the template) Event has ended. (outside the template: |event lead=none in the template) This is the lead text: 1 day, 11 hours, 43 minutes, 39 seconds this is the tail text. [refresh] Time to event: 1 day, 11 hours, 43 minutes, 39 seconds [refresh] (defaults) Event has ended. (defaults when |duration= is set and event has started) Event begins in 1 day, 11 hours, 43 minutes, 39 seconds [refresh] (defaults when |duration= is set and event has not yet started) Further, because this version of {{countdown}} diverges quite a bit from the current {{countdown}}, I'm think that I will make it its own template, perhaps {{countdown-ymd}}. —Trappist the monk (talk) 13:33, 27 April 2015 (UTC)

Moved to Template talk:countdown-ymd

Problem in module with parentheses

I noticed that simple usage like {{countdown|year=2015|month=1|day=1}} (date is in the past) gave "Lua error: bad argument #1 to 'ucfirst' (string expected, got nil)." I fixed that with some adjustment of the parentheses. Some other problems of the same nature still exist but I couldn't work out exactly what was wanted from the code so I left it for now. At any rate, when an event is in progress, the module attempts to show something like "There are 2 days until the event ends". However, that never happens because of a precedence problem which needs some parentheses to fix. I would have fixed it but I can't see why "or" was used at all and my thinking time has ended for now. The following shows that an "in progress event" does not currently display when it ends. This uses fixed wikitext so it won't change if the module is updated.

• {{countdown|year=2015|month=1|day=1|duration=365|duration unit=day|eventstart=EVENT START|eventend=EVENT END}} →

  EVENT START (refresh)

Johnuniq (talk) 03:50, 18 November 2015 (UTC)

Support refresh=no to disable the (refresh) button

This would be useful when it's used in other templates with another refresh/purge button already present. Maybe User:Johnuniq can help here? Headbomb {t · c · p · b} 15:03, 1 April 2019 (UTC)

@Headbomb: I fixed the problem I mentioned in the section immediately above this, and I implemented |refresh=no. The following demonstrates both. At the time I am posting this, the event is in progress and that did not work before.

• {{countdown|year=2019|month=3|day=1|duration=200|duration unit=day}} → The event has ended. (refresh)
• {{countdown|year=2019|month=3|day=1|duration=200|duration unit=day|refresh=no}} → The event has ended.

Johnuniq (talk) 06:50, 2 April 2019 (UTC)

Thanks. Headbomb {t · c · p · b} 15:17, 2 April 2019 (UTC)

Countdown of other values

Hi there I wanted to add to the Climate Clock countdown also the CO2-budget countdown, but I wouldnt know if there is a way to do a countdown that reduces the remaining CO2-budget with every update, instead of years/days/hours/minutes/seconds. But you would need to be able to define an amount of reduction per time unit. Something like the bottom countdown at this site: https://www.mcc-berlin.net/fileadmin/data/clock/carbon_clock.htm Nsae Comp

Does anyone know a way?

(talk) 08:23, 29 April 2023 (UTC)