rapids-datetime-string: like 'rapids-date-string', but second-precision

[jameslamb]

Contributes to rapidsai/build-planning#218

Complements rapidsai/shared-workflows#608

For conda builds, RAPIDS projects run source rapids-date-string and then thread the environment variable it sets (RAPIDS_DATE_STRING) through into conda package build strings, like this:

source rapids-date-string

(rapidsai/cuml - ci/build_cpp.sh)

context:
  ...
  date_string: '${{ env.get("RAPIDS_DATE_STRING") }}'
  ...

...

outputs:
  - package:
      name: libcuml
      version: ${{ version }}
      ...
      string: cuda${{ cuda_major }}_${{ date_string }}_${{ head_rev }}

(rapidsai/cuml - conda/recipes/libcuml/recipe.yaml)

In rapidsai/build-planning#218 we're moving from YYMMDD date components to YYMMDDhhmmss, and prefer to have a different variable name (RAPIDS_DATETIME_STRING) ... this introduces a new rapids-datetime-string for that purpose.

Notes for Reviewers

We can remove rapids-date-string soon

From GitHub searches, it seems to me that rapids-date-string and environment variable RAPIDS_DATE_STRING are only used in CI builds of RAPIDS conda packages.

Once all repos are switched over to rapids-datetime-string / RAPIDS_DATETIME_STRING, we could remove rapids-date-string.

Nice side benefit... that'll cut out some GitHub API calls from our CI, because builds we'll no longer execute this on every run of a ci/build_{cpp,python}.sh script:

gha-tools/tools/rapids-date-string

Lines 5 to 8 in 02ea00f

	if [ "${GITHUB_ACTIONS:-false}" = "true" ]; then
	WORKFLOW_DATE=$(rapids-retry gh run view "${GITHUB_RUN_ID}" --json createdAt | jq -r '.createdAt')
	RAPIDS_DATE_STRING=$(date -d "${WORKFLOW_DATE}" +%y%m%d)
	fi

[jameslamb]

/merge