Skip to content
This repository was archived by the owner on Jun 26, 2020. It is now read-only.

Ambiguous date marking #6

Open
peteihis opened this issue Jun 25, 2019 · 3 comments
Open

Ambiguous date marking #6

peteihis opened this issue Jun 25, 2019 · 3 comments

Comments

@peteihis
Copy link

This may be a bit trivial, but annoying never the less... This also is a more general problem, that just in the manual, but an example in rendering.html:

<!-- Creation date: 01/03/02 -->

So when? Probably the middle one is not the year, but still I would not bet if the year 2001 or 2002 or if the month is (depending on which year you want it to be) January, February or March. Comparing the marking to other files I know, that in this particular case the first one is the year, but there is no way of telling about the rest.

Some of the files don't have a date marked and that's fine too but from maintenance point of view, it'd be nice to know when that file has been edited last. As of formatting, the year should always be written in four digits and I'd suggest to write the month as an abbreviation rather than a number. For example:

<!-- Created: 2001-Mar-02 -->
<!-- Edited:  2019-Jun-25 -->

The benefit of the three-digit abbreviation as the month compared to the full name of a month is the constant field length, which improves readability.

@peteihis
Copy link
Author

Comparing the marking to other files I know, that in this particular case the first one is the year

NOT! In contents.html

<!-- Creation date: 21/02/02 -->

@Sailsman63
Copy link
Member

It probably depends on who worked on the file. European English speakers (Britain, esp.) tend to use dd/mm/yy, while U.S. prefers mm/dd/yy. Much of the rest of the world uses yyyy/mm/dd

Something to think about, but I really think that we sorry if need to review must of the manual anyway.

@peteihis
Copy link
Author

It probably depends on who worked on the file.

Yes it does. As a matter of fact I have a paper lying on my desk here with a date "6/16/2019, 7:43PM", where nothing is the way we usually have.

need to review most of the manual anyway

So true.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants