Package Distribution-Date

[Sergiy Radyakin]

Dear All,

"Distribution-Date" is an undocumented keyword that can be used in package description files to indicate the date when the package was last updated. This is evidenced from the source of the adoupdate.ado file.

I have not seen any package that would also specify the time besides the date. For example, all SSC packages indicate Distribution-Date in the format YYYYMMDD.

It seems from the code that the dates are compared as string literals.

I wonder if it is Ok then to timestamp the package distribution dates as
- YYYYMMDD-HHMMSS, for example?
- or perhaps YYYYMMDD-RR
- or even RRRRR?

(RR - revision number in that day, RRRRR - sequential revision number 1...inf)

This will be useful for packages that are updated multiple times per day.
Any insights and experience on this are much appreciated, especially if there are any recommendations on indication of time-zone and time-zone comparisons, in case the time component is ever interpreted as time, not just as string.

Thank you, Sergiy Radyakin

[Nick Cox]

As you're asking for comments: I have never felt the need for this. If you are updating a package several times a day -- presumably on your "own" website -- perhaps you should be flagging that somehow in free-form text.

[Sergiy Radyakin]

Dear Nick,

thank you very much for your comment. Indeed, we are talking about a site different from SSC.
I would still like to rely on an automatic solution (adoupdate command).

This seems to be an oversight and a bug in Stata.

real scalar edateofstr(string scalar s)
{
    real scalar    res
    real scalar    yr, mo, da

    if (strlen(s)==8) {
        yr = strtoreal(bsubstr(s, 1, 4))
        mo = strtoreal(bsubstr(s, 5, 2))
        da = strtoreal(bsubstr(s, 7, 2))
        if (yr<. & mo<. & da<.) {
            res = mdy(mo, da, yr)
            if (res!=.) return(res)
        }
    }
    return(date(s, "dmy"))
}

An oversight, because the timestamp is interpreted only as 3 components of the date, not allowing for anything else (time, version or revision identifiers).
A bug, because date(s,"dmy") will always return a missing value, and this was included seemingly to deal with the situations when the distribution date is anything different from YYYYMMDD.

Checking:

. di date("11-11-2021", "DMY")
22595

. di date("11-11-2021", "dmy")
.

This leaves no hope for updates that are more frequent then daily.
I hope that Stata developers can revise this limitation to permit including time or revision component for higher frequency updates. Perhaps for compatibility it can be specified as YYYYMMDD.rrrrr (with revision in the fractional part, thus the value remains a real scalar).

If there is still a possibility of a workaround within the currently released functionality, please let me know.

Sincerely, Sergiy Radyakin

[Leonardo Guizzetti]

This will be useful for packages that are updated multiple times per day.

I can't imagine a useful scenario for this. Even many highly-organized, frequently updated software projects (cf, github) adopt a "nightly" build approach where software is still released once a day, despite possibly multiple updates that day. Reading a bit into Nick's response, supposing that a program is released and then later that day, re-released with updates, the user can still force an installation that overwrites the previous version.

[Sergiy Radyakin]

adopt a "nightly" build approach where software is still released once a day, despite possibly multiple updates that day.

This is close. Why would I want to wait for the whole day? GitHub conveniently allows doing a release after every commit. More than one can happen in a day.

Reading a bit into Nick's response, supposing that a program is released and then later that day, re-released with updates, the user can still force an installation that overwrites the previous version.

Yes, correct, and this comes at the cost of ruining download/update statistics and generating extra traffic.

What would be the use of the following line in the StataCorp's code then?

return(date(s, "dmy"))