-
Notifications
You must be signed in to change notification settings - Fork 161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow packages to use ISO 8601 dates in their PackageInfo.g #2727
Comments
Cf. also gap-system/gap-distribution#20. I think we can implement this in a way that both formats will be permitted concurrently, and that Indeed, not a problem to detect whether the date is in |
Date := "28/08/2018" is converted by GAPDoc to "28 August 2018" in a manual front page, whereas |
I think that's a question to AutoDoc rather then to GAPDoc authors. AutoDoc extracts the date from PackageInfo.g, while GAPDoc - not. |
Indeed, AFAIK does nothing with title pages. But we can certainly add support to ISO dates in GAPDoc, too. Alternatively, we could simply convert the date from ISO 8601 to the "old" date format on the fly while loading, thus preserving full compatibility with any code that might for whatever reason try to parse these dates. |
I'm working on a PR to change |
If the date format is dd/mm/yyyy and InfoLevel InfoPackageLoading is set to at least 2 it prints a hint to change the format. Add validity check for dates Update relevant testfile Fixes gap-system#2727
If the date format is dd/mm/yyyy and InfoLevel InfoPackageLoading is set to at least 2 it prints a hint to change the format. Add validity check for dates Update relevant testfile Fixes gap-system#2727
If the date format is dd/mm/yyyy and InfoLevel InfoPackageLoading is set to at least 2 it prints a hint to change the format. Add validity check for dates Update relevant testfile Fixes gap-system#2727
If the date format is dd/mm/yyyy and InfoLevel InfoPackageLoading is set to at least 2 it prints a hint to change the format. Add validity check for dates Add normalisation of date format to AddPackageInfos Update relevant testfile Fixes #2727
If the date format is dd/mm/yyyy and InfoLevel InfoPackageLoading is set to at least 2 it prints a hint to change the format. Add validity check for dates Add normalisation of date format to AddPackageInfos Update relevant testfile Fixes #2727
If the date format is dd/mm/yyyy and InfoLevel InfoPackageLoading is set to at least 2 it prints a hint to change the format. Add validity check for dates Add normalisation of date format to AddPackageInfos Update relevant testfile Fixes gap-system#2727
If the date format is dd/mm/yyyy and InfoLevel InfoPackageLoading is set to at least 2 it prints a hint to change the format. Add validity check for dates Add normalisation of date format to AddPackageInfos Update relevant testfile Fixes gap-system#2727
If the date format is dd/mm/yyyy and InfoLevel InfoPackageLoading is set to at least 2 it prints a hint to change the format. Add validity check for dates Add normalisation of date format to AddPackageInfos Update relevant testfile Fixes gap-system#2727
If the date format is dd/mm/yyyy and InfoLevel InfoPackageLoading is set to at least 2 it prints a hint to change the format. Add validity check for dates Add normalisation of date format to AddPackageInfos Update relevant testfile Fixes gap-system#2727
If the date format is dd/mm/yyyy and InfoLevel InfoPackageLoading is set to at least 2 it prints a hint to change the format. Add validity check for dates Add normalisation of date format to AddPackageInfos Update relevant testfile Fixes gap-system#2727
It would be nice if packages could also specify the release date in ISO 8601 format, i.e., as
YYYY-MM-DD
. This is less ambiguous than the currentDD/MM/YYYY
(which e.g. Americans may confuse withMM/DD/YYY
).Besides needing to modify
lib/package.gi
and the documentation, it may also be necessary to modify the package distribution.This might be a good "first issue"?
The text was updated successfully, but these errors were encountered: