First Draft Uploaded. Does it relate to the ISO standards desirably?

[JohnLukeBentley]

Hi @njbart,

I've uploaded a BibliographicDatetimeFormat.pdf v0.1.1-draft (direct download) BibliographicDatetimeFormat.pdf v0.1.2-draft (direct download)

The chief purpose is to further our productive, but stalled, discussion on the feasibility issue of: what should be the relationship between our standard and ISO 8601:2016?

Could I burden you to read the draft? Then the following possible stances toward the relationship issue will make sense:

1. Have "The Bibliographic ISO 8601 profile ... provide the closest possible interpretation of the intentions of the authors of (|EDTF 8601 Profile - Annex C in ISO/DIS 8601-2:2016(e)|)"; and then apply our desired "The Bibliographic Standard-Transformation (The Transformation)". That is, to result in the formats stipulated by our "Bibliographic Datetime Format" overall. This is the model reflected in the draft.

2. Have "The Bibliographic ISO 8601 profile" apply directly to (|ISO/DIS 8601-1:2016(e)|) overall following the mere spirit of (|EDTF 8601 Profile - Annex C in ISO/DIS 8601-2:2016(e)|); and then apply our desired "Bibliographic Standard-Transformation (The Transformation)". That is, for a more (|EDTF 8601 Profile - Annex C in ISO/DIS 8601-2:2016(e)|) independent "Bibliographic ISO 8601 profile" and a slightly simpler document overall.

3. Have "The Bibliographic Standard-Transformation (The Transformation)" apply directly to (|EDTF 8601 Profile - Annex C in ISO/DIS 8601-2:2016(e)|) using all of conformance types - CONFORMS; DISAMBIGUATES; DELETES; OVERRIDES; and EXTENDS. That is, so Bibliographic Datetime Format does not itself use a ISO 8601 profile ("The Bibliographic ISO 8601 profile" is dropped). So all the rules under the transformation comprise the rule set we desire. This would yield a document simpler than in 2 and 1.

4. Create an ISO independent standard, without a Profile and Transformation, that carries the spirit of EDTF. An even simpler document.

5. Not bother with our standard at all.

6. Something else.

A few points about the status of v0.1.1-draft. For the sake of having something to push against, and seeing how a coherent model might work, I've chosen to come down on one side or the other on most issues. Most prominently: the standard name (Bibliographic Datetime Format); the aims of the standards (see Meta > Overview > Aims); and the set of rules. While those choices generally represent my current preferences I'm not necessarily strongly in favour of those choices.

However, I have put effort into making there be at least a chance I've gotten the rules right (at least out of the gate), relative to the stated aims. But there's plenty scope for challenging the rule set; and/or the stated aims. Indeed the raison d'etre of our creating a standard is so that debate over these matters is enabled.

And, just as with the authors of the ISO docs, BDF v0.1.1-draft probably contains errors, ambiguities, and omissions. Although now is not the time for scrutinizing the document for those: if any of those are glaring I'd like to know (particularly if they impact the model).

On the possible relationship stances to take I strongly favour 1 (the model reflected in the draft). It is the most complex of the 6 options (number 6 aside, being an unknown option). So it has that disadvantage. But I feel the model I've come up with, as manifest in the draft, tames that complexity in various ways. My hope is that, despite the complexity, any reader would more easily understand BibliographicDatetimeFormat.pdf v0.1.1-draft - by comparison with the experience of reading the ISO docs.

Anyway to repeat the chief issue in an alternative framing:

Does BibliographicDatetimeFormat.pdf v0.1.1-draft relate to the ISO standards desirably?

@plk, @inukshuk, @retorquere, @moewew, @Crissov, @danbri, and anybody else who is interested, you are welcome to weigh in on any of this. However, you are also welcome to save yourself some time and let @njbart and I discuss this (if he is available and willing). We'd then, if possible, offer a considered conclusion that we both endorse for you to respond to. I tap your names now chiefly to let you know there is movement on this.

@danbri I tap you given your reference to /plk/biblatex/ Datetimes. The draft ISO 8601-201x and EDTF from /schemaorg/schemaorg/ Add mechanism for describing uncertain dates.

Edit: Updated to BibliographicDatetimeFormat.pdf v0.1.2-draft.

[danbri]

Thanks for trying to move this along. My preference from a Schema.org perspective is to keep things as close to whatever ISO are likely to eventually say as possible, but acknowledging how difficult ISO are making this for everybody by hiding their works-in-progress. Our most pressing need is for a pattern to suggest in https://schema.org/temporalCoverage for use e.g. with dataset description, since the question often comes up: "how do we say that this dataset's temporal coverage starts at some known fixed point, and [at the time of description] continues indefinitely i.e. is [currently] ongoing?".

[danbri]

Within Schema.org I've made a specific stopgap proposal for open-ended date ranges, in part re-assured by your draft here. Can you offer any sanity checking? see schemaorg/schemaorg#1365 (comment)

[JohnLukeBentley]

@danbri thanks!

My preference from a Schema.org perspective is to keep things as close to whatever ISO are likely to eventually say as possible,

Note from (|BDF|, 8, sec. 2.3.4 Relationship to other standards):

This Bibliographic Datetime Format (BDF) has rules divided into two sections:

1. "The Bibliographic ISO 8601 profile", "BP" for short, an "ISO 8601 profile"; and
2. "The Bibliographic Standard-Transformation", or "The Transformation" for short, which is an instance of "A Standard-Transformation". This results in the formats stipulated by "Bibliographic Datetime Format" overall, "BDF" for short. ...

The Bibliographic ISO 8601 Profile is an ISO 8601 profile of another ISO 8601 profile: (|EDTF 8601 Profile - Annex C in ISO/DIS 8601-2:2016(e)|).

(|EDTF 8601 Profile - Annex C in ISO/DIS 8601-2:2016(e)|), because it is also an ISO 8601 profile, stands in relation to the larger standard(s) which contain it: (|ISO/DIS 8601-1:2016(e)|) and (|ISO/DIS 8601-2:2016(e)|).

... The Bibliographic ISO 8601 profile ... aims to provide the closest possible interpretation of the intentions of the authors of (|EDTF 8601 Profile - Annex C in ISO/DIS 8601-2:2016(e)|), consistent with providing a coherent standard. The Bibliographic ISO 8601 profile, in that sense, attempts to track (|EDTF 8601 Profile - Annex C in ISO/DIS 8601-2:2016(e)|).

So you could well follow the Bibliographic ISO 8601 profile only rather than BDF overall. That is, by ignoring the Bibliographic Standard-Transformation. In that case your "quick reference" will be, in effect, the left hand column of (|BDF|, 38 - 45, sec. 4.2 BP Versus BDF: VALID Examples). This is part of the motive for structuring the document as I have.

In doing so you'd be following my interpretation of (|EDTF 8601 Profile - Annex C in ISO/DIS 8601-2:2016(e)|). Because my interpretation hasn't undergone any kind of community scrutiny there's the level of general risk that this would entail.

However the (|ISO/DIS 8601-1:2016(e)|) and (|ISO/DIS 8601-2:2016(e)|) I followed and cite are those that I purchased from ISO quite recently on 2018-06-20. And it turns out that this version is identical to the ISO docs last available from LOC, apart from some initial pages: cover, copyright page, and table of contents. From and including the foreward all the page numbers are synchronized and the content word for word identical (as far as my quick comparison detects).

So, consider your sanity verified ... you are correct that:

• Double dots (..) for "open" in an interval is ISO's current public stipulation; and
• Like all parts of the ISO document it is at risk of being changed; but
• Using this as an interim measure is probably a good bet (if you want to stick as close to ISO as possible). This is the view, for example, that @plk has taken with biblatex (also on the basis that changing to another symbol, if required, should be relatively simple).

Note, by the way, that the Open in interval rule is identical in the the Bibliographic ISO 8601 Profile and in BDF overall (see, |BDF|. 38, sec. 4.2 BP Versus BDF: VALID examples).

All that has helped crystallize that my "editor's note" (BDF, 9, 2.3.5 Conformance requirement)

{Perhaps there needs to be an additional explicit note about it being OK to use the Bibliographic ISO
8601 Profile alone ... constituting conformity with that profile rather than BDF overall}

... should become part of the document as ....

Conformance can be claimed for the Bibliographic ISO 8601 Profile alone.

With regard to schemaorg > Add mechanism for describing uncertain dates #242 see BDF sections: 2.4.7 Terms and definitions (pp. 13 - 14); 3.1.10 Qualified date (29 - 30). Does that take care of all your needs there (I've only skimmed the thread)?

By way of further illustrating the nature of the current BDF it might be useful to address @retorquere's comments at schemaorg/schemaorg#1365 (comment)

1982-Q4-XX // A year-quarter, with the day unspecified. Some day in the quarter.; not sure what the purpose of XX is here (wouldn't 1982-Q4 say the same?) other than perhaps than saying it was a single day event -- but if that is the purpose, how do I express a week-long event in 1982-Q4?

Noting that the merits of particular rules are something for proper debate down the track there's a few things to say here. The Extending quarters rule (|BDF|, 35, sec,. 3.2.5 Quarter), as I mention there, quite possibly shouldn't exist for the reasons I mention. However, if it were to exist in it's current form the unspecified format follows the pattern of the Bibliographic ISO 8601 Profile (BP) Unspecified rule. There, for example, we have ...

Year and month specified, day unspecified; Some day in a month, YYYY-MM-XX; 2019-02-XX

Some unspecified day in a specified month, like 2019-02-XX, would be distinct from specified month, like 2019-02.

But you could quite readily take a range of views about unspecifieds in quarters, in the pending debates over rules. For example, that they should not exist on the basis that a quarter, if present, will be the highest level of precision.

Neither in the Bibliographic Datetime Format overall, nor in the Bibliographic ISO 8601 Profile is there provision for expressing ordinal weeks (whether or not we allow quarters). Partly because (|EDTF 8601 Profile - Annex C in ISO/DIS 8601-2:2016(e)|) does not provide for expressing ordinal weeks. We only find provision for ordinal weeks in (|ISO/DIS 8601:2016(e)|) overall.

I still don't like <no value> for unknown, both for conceptual reasons (explicit over implicit) but also pragmatic reasons (I have to parse date soup, and nothing-means-something makes my life harder).

I agree. In the pending debate over rules there'd be a discussion to be had over which principle should take priority on this matter:

• That even though the Bibliographic Standard-Transformation departs from (|EDTF 8601 Profile - Annex C in ISO/DIS 8601-2:2016(e)|) it remains largely consistent with (|ISO/DIS 8601:2016(e)|) overall ... and we shouldn't try to too violently depart from (|ISO/DIS 8601:2016(e)|) overall; versus
• Some ISO rules are so egregiously wrong that we should go with an alternative (like having an explicit symbol for unknown).

BDF, in it's current model, would allow for either principle to win out. I mean that to speak in favour of the current model.

I am not sure what the strikeouts mean in the text. Are they part of the date format, or ways of saying "there used to be something here, but we've decided to do it another way"?

That later is more the meaning. It signals a "DELETING" rule. The only rule this applies to is the Century Rule (see, |BDF|, 29, sec. 3.1.9 Century; 34, sec. 3.2.4 Century), although there are DELETIONS in other rules at the clause level (see e.g., |BDF|, 34, "Overriding years exceeding four digits rule"). For a full explanation see (|BDF|, 6-8, secs. 2 Meta > 2.3 External Consideration > 2.3.1 Conformance types - 2.3.4 Relationship to other standards)

Edit 01: "2.3.4 Conformance types" to "2.3.4 Relationship to other standards"

Edit 02: "apart some" to "apart from some".

Edit03: Made <no value> visible in "I still don't like <no value> for unknown".

[retorquere]

Some unspecified day in a specified month, like 2019-02-XX, would be distinct from specified month, like 2019-02.

I had forgotten about that. I was still thinking about uu used for that.

[JohnLukeBentley]

Hi @plk, @inukshuk, @retorquere, @moewew, @Crissov, and @danbri ...

@njbart is missing in action. To the extent that you have the time: could I burden you to read the second draft BibliographicDatetimeFormat.pdf v0.1.2 (direct download) and comment on the issue at hand?

If useful, from https://github.com/JohnLukeBentley/open-datetime-standard-bootstrap/releases are:

• BibliographicDatetimeFormat-ChangesSinceLastVersion.pdf
• CHANGES.md

[retorquere]

@njbart comes and goes; I have a sense he's ludicrously busy, and that he chimes in when he can.

It looks OK to me, except to my by now well-known exception to unknown. Especially

/ // Both datetimes unknown.

seems to me will only work for dates that are clearly delineated as such; picking out this pattern in text is going to be impossible.

[JohnLukeBentley]

Thanks @retorquere.

As mentioned in our discussion elsewhere that rule, the format for unknowns as a blank, is ripe for being "Transformed" so we come up with something else in our standard. That'll depend on how our collective view shakes out about the extent we wish to remain close to, versus depart from, ISO in our BDF (overall) format. I think the advantage of the present structure of the document is that it facilities that view to go in either direction.

But in "3.2 The Bibliographic Standard-Transformation (The Transformation)" (in error currently written as "3.2. Transformation (The Transformation)"), for the moment, I've not OVERRIDEN blank for unknowns as I've had @plk's instincts in mind. That is, when faced with what to do about biblatex, the draft ISO standard, and prior alternative symbols in biblatex (for unknowns and open), plk chose to go with the ISO standard (all the being while at the ready to change if ISO changes).

... assuming having our own standard has merit at all.

Edit 01: Added "what to do about biblatex".

Edit 02: moved errant comma.

Edit 03: Added "... assuming having our own standard has merit at all."

[retorquere]

Fair enough. I don't actually encounter the "picking out from text" problem myself (dates are always clearly delineated for me).

I do suffer from another problem, that the / delimiter for date ranges is mildly problematic when you don't know when the dates you get are well-structured (which for me is the rule rather than the exception), and I have to figure out whether 8/2008 is august 2008 (which is usually the case for my purposes), or whether it is the year 8 until the year 2008 (which is how the EDTF parser would pick it up). I have a bunch of heuristics in place to parse dates before the EDTF parser gets to it to pick these out.

AAMOF I would have much preferred .. to be the range symbol (and something else the open symbol, like *) so that 8/2008 and 8..2008 would be unambiguous, but that runs into the same problem with @plk's instincts.

[JohnLukeBentley]

Yes it's easy to argue that ISO should have gone with something apart from / as the interval separator; and something else for "open" - for the reasons you mention. Blank for unknown is the egregious case.

But given ISO's draft stipulations there's a few possible stances to take toward ...

the extent we wish to remain close to, versus depart from, ISO in our BDF (overall) format.

Those stances depend on what an implementer (such as yourself) would like to do with their parser. Support :

• ISO only (optionally in addition to customary formats e.g. 12/06/2018)
• BDF only (optionally in addition to customary formats e.g. 12/06/2018)
• ISO and BDF (optionally in addition to customary formats e.g. 12/06/2018)

If the last stance is chosen then, for example, having in BDF a non-blank symbol for unknown may well make for the superior standard; but wouldn't exactly get around the blank problem given you've chosen to support ISO also.

That might count against have BDF OVERRIDING blanks for unknowns. That is, it might be better to be less divergent from ISO if you want to support ISO and BDF.

By contrast if you want your parser to support BDF only, because we've made BDF such that it parses really well (and has other benefits), then that might free us up to be more divergent from ISO (with the faint hope that, over time, ISO might come to see the error of their ways and adopt the superior standard).

[retorquere]

I don't object pragmatically, and for date parsing, pragmatic is important. Aligning with a standard, even a flawed one, has all the benefits you highlight.

[JohnLukeBentley]

To be explicit: I'm not taking a view here. But, yes, we might decide that aligning more closely with a flawed standard is the way to go. Perhaps @plk or @inukshuk (also in-the-thick-of-it implementors) will be able to divine a strong view to take, one way or the other.

On the particular rules I will mention that, having been through the exercise of ironing them out, I was most happy to get clear in The Bibliographic ISO 8601 Profile (BP) on the separator rules (sec "3.1.2 Separators") ISO intends (and also see that they are ambiguous about it in places);

And correspondingly the most valuable part of The Bibliographic Standard-Transformation, for me, is probably the Overriding date-and-time separator rule and the Overriding timezone designator separator rule. That is, in ENCOURAGING space separators, 2019-02-28 18:34:01 Z but permitting no separator, 2019-02-28T18:34:01Z.

[JohnLukeBentley]

@plk, @inukshuk, @retorquere, @moewew, @Crissov, @danbri

At https://www.iso.org/standard/70907.html (ISO/FDIS 8601-1) the status appears to be "50.60 Close of voting. Proof returned by secretariat"; with a prior step, 50.00, having a 2018-07-30 date against it. The next step is publication.

https://www.iso.org/standard/70908.html ((ISO/FDIS 8601-2) hasn't moved. But that could well be an web site update oversight.

So there has been movement by ISO and it is looking likely the whole ISO standard will be published Real Soon.

It might be worth waiting to see what it looks like before assessing the worth of my proposal, the Bibliographic Datetime Format.

[Crissov]

It also says “Publication date: 2018-12” for Part 1, none yet for Part 2. I think separate advancement is reasonable. For this project, however, Part 2 seems much more relevant.

[JohnLukeBentley]

Thanks @Crissov. On another look, and on your noticing a "publication date", the status appears to be:

• https://www.iso.org/standard/70907.html (ISO/FDIS 8601-1) "50.00 Final text received or FDIS registered for formal approval" with this step dated 2018-07-30; Publication Date "2018-12". and
• https://www.iso.org/standard/70908.html ((ISO/FDIS 8601-2) "50.00 Final text received or FDIS registered for formal approval" with this step dated 2018-10-10; Publication Date none.

Whether reasonable or not it looks like part two is lagging by about 2 months.

Part two is more directly relevant to our current concerns, yes. So the best guess at the date when both Part One and Part two would be available is 2019-03-XX%.

Sort of close, but not really close enough that I'd want to dependent projects (biblatex, edtf.js, pandoc, etc) to hold their breath. So I continue to lobby for feedback on the feasibility of Bibliographic Datetime Format (BDF), with a view to developing it for use, without having to wait for ISO.

[moewew]

From my perspective it makes little sense to move before ISO 8601 is released. I haven't followed the entire development here closely and I didn't have time to read the 50-page report on the BDF, so all I will say is that to my eye an 'ISO profile' seems worthwhile, but a competing and possible incompatible standard less so.

I would like to point out that I don't really think it is a great idea to support several encouraged and discouraged formats. (E.g. T vs space as date-time separator.) I quite like the T in ISO 8601, so I'm obviously biased, but I can't see what is to be gained by allowing and encouraging a space instead except for a fragmentation and complication of the system.

I'm also worried that the format 'wants too much'. I was sceptical initially that time-precision dates were useful for the average user in biblatex. I had seen a request once or twice in the years before it was introduced (only in forums, though, not sure if anything ever got to an official bug tracker), but it wasn't a highly requested feature. I can sort of see the use for some applications, but the huge majority of users will never use it (most are happy if they can have years or year ranges - that's it, some even delete the month to obtain a year-only date). Supporting all this in the output requires a huge machinery and can make things that 'should be easy' quite a bit more difficult. For biblatex supporting the input also means supporting the output and some things that look nice conceptually are quite hard to get right in natural language (see for example the extradate position: plk/biblatex#644). I'd say we are looking at diminishing returns at some point if we go much further than YYYY-MM-DD/YYYY-MM-DD.

[JohnLukeBentley]

@moewew thanks very much for that.

I'd had problems with github notifications a few months back (where they were falling into yahoo's spam trap) so it is good, as a start, to see this is not necessarily a universal problem.

Yes I'm not expecting anyone, at this stage, to necessarily read the whole BibliographicDatetimeFormat.pdf. And from what you've written it looks like you've skimmed it sufficiently to get a handle on the broad issues.

Two format sets

an 'ISO profile' seems worthwhile, but a competing and possible incompatible standard less so.

Indeed that sentiment is consistent with your prior statement (the original post for which I can no longer find) ...

Even if biblatex and a few other bibliography-related tools were to use it, it would still just be 'that loony bibliography date format used by those tools that couldn't be bothered to adopt the proper ISO date format'.

... and that statement was a large part of the inspiration for my dividing BibliographicDatetimeFormat.pdf into the two format sets (as you've observed): the Bibliographic ISO 8601 Profile (BP); and the Bibliographic Datetime Format (BDF). BDF being based on a "Standard-Transformation" (a concept I define) of BP.

That enables someone to value BibliographicDatetimeFormat.pdf for BP only, and thereby ignore BDF.

We've already seen that approach bear some fruit in the example of @danbri who, above, was swooping in from Schema.org with a narrow interest in what ISO had to say on a few formats.

Assessing whether BDF (the format not the document as a whole) has value is, then, a matter of looking at "3.2 Transformation (The Transformation)" and deciding whether, beyond or in contradiction of what ISO stipulates, any of the rules have value; and/or whether one can imagine a rule that should be there.

So debates could be aimed at BP or BDF separately.

Bibliographic Datetime Format (BDF) aims

On BDF you helpfully raise the issue of the worth of encouraged and discouraged formats, through the exemplifying lens of separators. What is to be gained is a furthering of some aims for BDF that I've stipulated in "2.2.2 Aims":

The formats stipulated by Bibliographic Datetime Format (BDF) are chosen to satisfy the following
aims:

• ...
• .2. Format handling kinds (to coin a phrase) that:
  • Work well as an input, storage, and output format. That is, because the format is both
    human readable and machine parsable. E.g. 2019-02-28 18:34:01 +11:00 works well in
    all three contexts; then, failing that,
  • Work well as a storage format. E.g. A software system might permit (a non BDF) 380 BCE
    (or 380 BC, or -0379) input, store this as a BDF VALID -0379, and output this as (a non
    BDF) 380 BCE (or 380 BC, or -0379), depending on user preferences. That is, -0379
    works well stored but not input or output as most users aren't aware of, let alone used
    to, the traditional calendar to astronomical calendar conversion.
• ...
• .5. As far as practical stipulate either: one VALID format; or, failing that, an ENCOURAGED
  format, where multiple options are available for a representation;

That is, I'm offering those aims as worthy. Specifically that, unlike (|EDTF:LOC|) or (|EDTF 8601 Profile - Annex C in ISO/DIS 8601-2:2016(e)|), BDF ought not be narrowly aimed at being a storage format but be aimed at trying to work as as an input, storage, and output format - as far as possible.

If we decided BDF, broadly, had value then part of that work would involved debating those aims. But if the aim 2 was endorsed then the role of aim 5, allowing for multiple VALID formats with only one format promoted as ENCOURAGED, is to:

• Promote one choice for most cases, thereby making the standard simpler in a sense; while allowing for
• Alternative formats in the rarer cases; and
• Some degree of compatibility with (|EDTF 8601 Profile - Annex C in ISO/DIS 8601-2:2016(e)|).

So, for example, given that under BDF space separators are ENCOURAGED then something like 2019-02-28 18:34:01 +11:00 is ENCOURAGED (for readability reasons). If, however, a standard follower found either that their software stack couldn't handle spaces; or there was a need to be compatible with (|EDTF 8601 Profile - Annex C in ISO/DIS 8601-2:2016(e)|) - then 2019-02-28T18:34:01+11:00 is available to them under BDF (the format).

Bibliographic ISO 8601 Profile (BP)

You express scepticism about the worth of date-and-times (as I now call them), as in 2019-02-28T18:34:01+11:00 or 2019-02-28T18:34 (with or without space separators), in this Bibliographic context.

In general adding features to any software system involves a greater than linear increase in effort to develop, test, and maintain that system. Your pointing to the extradate date issue, plk/biblatex#644, does indeed illustrate this in our case. So you are right to think about the weight of that expense. I think you are also right that bibliographic date-and-times will remain the less usual case for the future.

However, for me the following reasons override those concerns:

1. I think the need for bibliographic date-and-times will be come greater (although never the usual case) as we continue to move from paper based to digitally based publishing. Articles, comments, blog posts, emails, tweets will often have a creation or update date-and-time;
2. There may well be a chicken and egg thing at play: it might be that bibliographic authors are unused to using date-and-times, partly hamstrung by convention, and that if available they'll become more popular (although I don't think so popular as to become the more usual case .... I think a plain year is going to remain the main bibliographic datetime use).
3. Perhaps most significantly, date-and-times are VALID under (|EDTF 8601 Profile - Annex C in ISO/DIS 8601-2:2016(e)|, 29, sec. C.4.2 Date and Time) at level 0. BP, therefore, has it that date-and-times are VALID. So if your software system, such as biblatex, wanted to claim support for either (|EDTF 8601 Profile - Annex C in ISO/DIS 8601-2:2016(e)|) or BP then your software system would have to support date-and-times.

The current status of BibliographicDatetimeFormat.pdf

Given the current lack of response, your (moewew) response aside, from the two main implementers (@plk - biblatex; @inukshuk - edtf.js) and @njbart ... then any potential development of BibliographicDatetimeFormat.pdf must necessarily be stalled. That is, quite independently from the issue of the timing of ISO's publication.

In that case I'll resume my datetime testing of biblatex, and other software projects, having BibliographicDatetimeFormat.pdf in the pocket to serve as: an aid for clarifying conceptual or ISO datetime issues; and as a handy repository of canonical test cases. At the very least, in other words, BibliographicDatetimeFormat.pdf in its current state helps (I hope) clean up some ambiguity in (|ISO/DIS 8601:2016(e)|) ... although it remains to be seen if BibliographicDatetimeFormat.pdf introduces ambiguities of its own.

In the mean time if anyone (coming in from any part of the interwebs) wants to revive (potential) development of BibliographicDatetimeFormat.pdf for any purpose ... I'll be all ears.

[JohnLukeBentley]

@inukshuk has pointed to an illuminating post on the EDTF mailing list by Ray Denenberg.

Evidently, he is the chair of the relevant ISO working group and that may well open a backdoor (via the EDTF mailing list) to engage with ISO. I'm given special hope in virtue of him having "brought edtf to ISO".

I intend to talk about BibliographicDatetimeFormat.pdf with Ray on the EDTF mailing list soon.

[JohnLukeBentley]

EDTF has recently been (updated and) published (2018-10-22): http://www.loc.gov/standards/datetime/edtf.html