Subject: [rfc-i] Requesting feedback: date formats in RFCs

From: Heather Flanagan <[email-masked]>
Date: Tue, 1 Oct 2019 14:10:39 -0700

Hola a todos!

So, now that I have a new copy of draft-flanagan-7322bis out, I want to open up the floor for a particular discussion regarding date format. This has come up on the xml2rfc-dev list, but is something that should have a wider engagement.

You’ll see (potentially) a variety of different date formats used in RFCs. 

- Month Year
- Day Month Year
- Month Day, Year

And in those options, sometimes there will be numerals for the day and/or the month, and sometimes not. We won’t discuss the variations in punctuation that may be involved, since that usually isn’t a problem in our typical use cases. 

So, that said, I’d like to discuss a possible change that has us use ISO 8601 format across the board.

Reasons for it:
* consistency within an RFC
* sortable date logic

Reasons against it:
* aesthetics (and with that, possible readability)
* inconsistence with past RFCs

And probably a few more arguments either way.  Does the community have strong feelings about making a change? References (as an example) would look like this:

   [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core,"
   IETF, RFC 3080, DOI 10.17487/RFC3080, 2011-03, <https://www.rfc-
   editor.org/info/rfc3080>

   [RFC-STYLE] Flanagan, H. and S.  Ginoza, "RFC Style Guide", Work in
   Progress, Internet-Draft, draft-flanagan-style-04, 2019-10-01

The header of an RFC would (using the TXT format for discussion purposes) look like:

Network Working Group                                        H. Flanagan
Internet-Draft                                                 S. Ginoza
Obsoletes: 7322 (if approved)                                 RFC Editor
Intended status: Informational                                2019-10-01
Expires: 2020-04-03
The Boilerplate text would look like:
   This Internet-Draft will expire on 2020-04-03.

No decisions have been made here (though you’ll see a mix of some of those date formats in 7322bis and in current xml2rfc outputs). Feedback is welcome!

-Heather

_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 2 Oct 2019 10:21:46 +1300

> use ISO 8601 format across the board

Yes please. Long overdue.

Regards

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 1 Oct 2019 23:24:53 +0200

Hi Heather,

Looking at the list of data formats by country in wikipedia:

  https://en.wikipedia.org/wiki/Date_format_by_country

and the overview by day/month/year order:

  https://en.wikipedia.org/wiki/Date_formats

it seems clear to me that we need to make an effort to make our choice
readable not only to people who happen to use the same day/month/year
element order we choose.

For this reason, I strongly advocate using month names rather than numbers,
and using 4-digit years.  If this is done, it is possible to figure out the
date that is meant even if it doesn't match the date format one is used to.

Most countries covered in https://en.wikipedia.org/wiki/Date_formats
use either DMY or YMD order, so I'd suggest using either '1 October 2019'
or '2019 October 1' over 'October 1, 2019'.  Of those two, it seems to
me that '1 October 2019' is the one most easily read.

Best regards,

	Henrik

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 1 Oct 2019 15:32:47 -0600

> Yes please. Long overdue.

+1 to ISO 8601.

/psa

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 2 Oct 2019 10:35:25 +1300

Henrik,

I have no doubt that ISO had this debate before they settled on a pure big-endian numeric format. Do we really want to rehash it? Admittedly we publish in English, so using English month names isn't unreasonable, but I've preferred the ISO format since I first came across it in 1977, which I can be precise about because the first date I saw in that format was 1977-05-17, the date of a particular version of the SINTRAN III operating system from Norsk Data ;-).

Regards
   Brian

---

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 02 Oct 2019 07:49:04 +1000

Definitely ISO8601. ISO recently updated it:

https://www.iso.org/standard/70908.html

There's all sorts of exciting new stuff in there.

Of course here at IETF we have RFC3339 which is based on ISO8601. It could be useful to update RFC3339 to cover at least a subset of the new things that ISO have added.

Cheers,

Bron.

--
 Bron Gondwana, CEO, Fastmail Pty Ltd
 [email-masked]

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 1 Oct 2019 17:52:18 -0400

I agree, +1 for ISO 8601. We ARE an SDO, after all :-)

Cheers,
Andy

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 1 Oct 2019 23:54:47 +0200

Hi Brian,

Yes, I'm afraid that having made too many mistakes when reading numeric
dates in British and American numeric-only formats (Sweden uses the ISO
numeric format, and has done so since the 1960es, I think), I'm quite,
quite certain that I don't want to inflict pure numeric dates on readers.

For situations where machine-readability (and sortability in particular)
is desired, then the ISO format is superior.  But not for our use case.

I find it mildly amusing that in RFC 3339, month names are used in several
places in the prose in order to make it easy to read and understand the
text, for instance in Section 5.8 and Appendices B and D.

I think the use case here is similar, and I think the reason I gave below
for making it easy for everybody worldwide to read publication dates
of RFCs (as well as draft dates) stands, and leads to using month names,
rather than numbers.

As for the ISO having had this debate, it is quite likely; but that does
not imply that the use case they wanted to address matches our.

Best regards,

	Henrik

On 2019-10-01 23:35, Brian E Carpenter wrote:
> Henrik,
> 
> I have no doubt that ISO had this debate before they settled on a
> pure big-endian numeric format. Do we really want to rehash it?
> Admittedly we publish in English, so using English month names isn't
> unreasonable, but I've preferred the ISO format since I first came
> across it in 1977, which I can be precise about because the first
> date I saw in that format was 1977-05-17, the date of a particular
> version of the SINTRAN III operating system from Norsk Data ;-).
> 
> Regards
>    Brian
>

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 2 Oct 2019 00:03:56 +0200

Hi Andy,

> I agree, +1 for ISO 8601. We ARE an SDO, after all :-)

And ISO 8601 is titled "Data elements and interchange formats
 – Information interchange – Representation of dates and times"

This does not match the use case here, except in a very broad sense.

For dates, Sweden, where I live, has been using the yyyy-mm-dd numeric
format since long before it became an ISO standard.  But I still would
not use numeric months in all contexts.  In speech, and text for primarily
human consumption, it's inferior.

Best regards,

	Henrik

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Tue, 1 Oct 2019 22:13:19 +0000

On 10/1/19, 5:11 PM, "rfc-interest on behalf of Heather Flanagan" <[email-masked] on behalf of [email-masked]> wrote:

    Hola a todos!

    
    - Month Year
    - Day Month Year
    - Month Day, Year

    
    Reasons for it:
    
    Reasons against it:

       [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core,"
       IETF, RFC 3080, DOI 10.17487/RFC3080, 2011-03, < https://www.rfc-editor.org/info/rfc3080>

    

Hi Heather,

I have no problems with using 2019-10-01. It's unambiguous, readable, mostly universal, and even lexically sound.

However, both 20191001 and 2019-10-01 are valid date representations under iso 8601. So just saying "iso 8601" is ambiguous -- you need to add more info as to how iso 8601 is being used.

	Tony

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 1 Oct 2019 16:23:42 -0600

> However, both 20191001 and 2019-10-01 are valid date representations under iso 8601. So just saying "iso 8601" is ambiguous -- you need to add more info as to how iso 8601 is being used.

Yes, RFC 3339 is our friend.

/psa

---

From: Heather Flanagan <[email-masked]>
Date: Tue, 1 Oct 2019 15:29:53 -0700

> On Oct 1, 2019, at 15:24, Peter Saint-Andre <[email-masked]> wrote:
> 

Fair enough. I am specifically referring to the use with dashes in the prose of an RFC. Date representations may vary in code, examples, formal language, and possibly a few other areas I am not thinking of off the top of my head.

-Heather

---

From: Ronald Tse <[email-masked]>
Date: Tue, 1 Oct 2019 22:35:52 +0000

Hi Heather et al.,

Thank you for bringing up ISO 8601 (and Bron for mentioned the exciting stuff). As one of two editors of the new ISO 8601 series (the other is Ray Denenberg of LC), I’d like to clarify:

- ISO 8601 is now a two part series comprising of ISO 8601-1 and ISO 8601-2. The first part covers all representations of the old ISO 8601:2004, including YYYY-MM-DD.

- Machine-readability has always been important, but ISO 8601-1 and its predecessors uses the phrase "information interchange” in its scope. Our intent with the new series title “Date and time — Representations for information interchange” was supposed to cover information interchange for both human and machine. (that said, how readable the timestamp representation by humans is another matter)

- ISO 8601-2 specifies a new “ISO 8601 profile” which is a mechanism to allow organizations to specify what ISO 8601 features are used. Annex A of ISO 8601-2 demonstrates how the EDTF format uses ISO 8601 features. It’s kind of a generic way of specifying RFC 3339.

- In the new ISO 690 which specifies referencing and citation guidelines, dates follow the ISO 8601 formats. e.g. the dates look like Heather’s examples provided.

P.S. And we’d be happy to provide any assistance on this matter for RFCs or 3339!

Kind regards,
Ron

_____________________________________

Ronald Tse
Ribose Inc.

On Oct 2, 2019, at 6:13 AM, HANSEN, TONY L <[email-masked]<mailto:[email-masked]>> wrote:

On 10/1/19, 5:11 PM, "rfc-interest on behalf of Heather Flanagan" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

   Hola a todos!

   - Month Year
   - Day Month Year
   - Month Day, Year

   Reasons for it:

   Reasons against it:

Hi Heather,

Tony

_______________________________________________
rfc-interest mailing list
[email-masked]<mailto:[email-masked]>
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 1 Oct 2019 23:39:59 +0100

Hiya,

On 01/10/2019 22:10, Heather Flanagan wrote:
>  to discuss a possible change that has us use ISO 8601 format across the board.
> 
> Reasons for it:

Those don't seem to rise to the level of justifying a new
"MUST" level requirement. So I'd say leaving it as-is is
better than making a change.

> And probably a few more arguments either way. 
> Does the community have strong feelings about making a change?

Not a strong opinion, no. But an opinion nonetheless and
one I hope is weighed on its merits and not my vehemence:-)

Cheers,
S.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 1 Oct 2019 22:53:29 +0000

Agreed.

Styling can make it "prettier" if that is needed.

    
    
    Regards

---

From: S Moonesamy <[email-masked]>
Date: Tue, 01 Oct 2019 15:41:44 -0700

Hi Heather,
At 02:10 PM 01-10-2019, Heather Flanagan wrote:
>So, that said, I'd like to discuss a possible change that has us use 
>ISO 8601 format across the board.
>
>Reasons for it:
>And probably a few more arguments either way.  Does the community 
>have strong feelings about making a change? References (as an 
>example) would look like this:
>

I'll comment on the two examples.  In the first one, the reader has 
to figure out whether the information being conveyed is a date.  In 
the second one, the reader has to figure out whether the digits after 
the year denotes the month or the day of the month.  If I am not 
mistaken, the rationale in CMOS is to avoid ambiguity given that 
dates in the United States are written differently in comparison 
with, for example, the United Kingdom.

It is easier to have the name of the month instead of an ISO 8601 as 
there isn't any ambiguity.  I suggest trying "text to speech" to 
understand what information.

Regards,
S. Moonesamy

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 1 Oct 2019 16:01:55 -0700

> with, for example, the United Kingdom.

As far as I know, in both the US and the UK, the format YYYY-XX-ZZ is
always YYYY-MM-DD. It's only XX-ZZ-YYYY that is confusing.

-Ekr

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 1 Oct 2019 19:44:20 -0400

> better than making a change.

It is not a requirement, it is a choice. The HTML outputification tool will
produce one date format.

It needs to be a logical format which means big-endian or little endian.
The US format is ridiculous and dangerous. The ISO version is not my
favorite but the sort semantics argue for it as does the fact that
bigendian is network byte order and also the order in which arabic numerals
are presented in Western scripts.

Rather ironically, Arabic uses a little endian approach but since it is a
right-to-left script, the numbers turned into big-endian when they were
adopted in Roman.

That said, I always use the month precisely to avoid ambiguity.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 2 Oct 2019 05:34:53 +0200

On 01.10.2019 23:21, Brian E Carpenter wrote:
> ...

Absolutely.

Best regards, Julian

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 2 Oct 2019 00:50:35 -0400

I also support use of the ISO format (with dashes).

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 [email-masked]

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 2 Oct 2019 05:41:23 +0000

On 2019/10/02 08:44, Phillip Hallam-Baker wrote:

> Rather ironically, Arabic uses a little endian approach

Well, yes and no.

When numbers are spoken (or written in letters), starting with the units 
and going up (10s, 100s,...) is indeed one way to do it. The other is to 
just invert tens and units, very similar to German (and to what English 
does from 13 to 19), but otherways go from big to small numbers.

There's also a system of writing numbers with letters, similar to 
Hebrew, and in that system, it's larger values to the right, which is 
big-endian because Arabic letters are written right-to-left. (see near 
the bottom of 
https://www.languagesandnumbers.com/how-to-count-in-arabic/en/arb/)

> but since it is a

First, the Arabic-Indic numerals used with Arabic came from Indic 
numerals, which are and were written big-endian left-to-right. The Arabs 
didn't change the visual order. I don't know what they do when they 
write a number out, it may depend on how they speak  (see start of this 
mail). My mother tongue being German,  I sometimes write the tens first 
and sometimes write the units first. Arabs may do similar things.

In Unicode, Arabic-Indic numerals (U+0660-U+0669) are strong 
left-to-right, which means that they encode numbers big-endian. That 
makes them easier to parse and process. But it is also the reason that 
for Arabic, bidirectional rendering is always needed, even if there are 
no foreign words in a text.

Regards,   Martin.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 2 Oct 2019 11:29:23 +0200

> So, that said, I’d like to discuss a possible change that has us use ISO 8601 format across the board.

I can see only two justifiable outcomes:

— leave things as they are (legacy argument, consistency argument);
— move (closer) to ISO 8601.

I don’t have a strong preference (actually I do, for the only reasonable way to write dates, which is ISO 8601, but I don’t want to be part of foisting reasonableness on other people who may have other preferences).

Grüße, Carsten

---

From: Dan York <[email-masked]>
Date: Wed, 2 Oct 2019 11:50:16 +0000

Heather,

On Oct 1, 2019, at 5:10 PM, Heather Flanagan <[email-masked]<mailto:[email-masked]>> wrote:

<snip>

I would also support changing to ISO 8601 with dashes.

I do understand and agree with Henrik’s argument that there can still be ambiguity and that using month names can be clearer. I agree from a clarity point-of-view. But in doing so you then open up additional permutations of upper/lowercase, short (Oct) versus long (October), etc. All of which can certainly be dealt with and normalized in the publishing process. But during the Internet Draft stage, where so many documents live, we could wind up with all these various variations.  Standardizing on the imperfect but very structured ISO 8601 (with dashes) would give us consistency throughout the process.

My two cents,
Dan

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 2 Oct 2019 09:38:36 -0400

I'm with Henrik here. The ISO format is fine for computer processing, 
but for human reading and comprehending of documents I find the spelled 
out month to be much preferable. I primarily think of months by name 
rather than number. So every time I read a date with numeric month I 
have to make a mental translation (however small) to put it in a form 
that I can comprehend.

Similarly, I often prefer dates to also include the day of week, though 
often the desire to have a shorter date string argues against that.

	Thanks,
	Paul

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 2 Oct 2019 15:49:36 +0200

On Oct 2, 2019, at 15:38, Paul Kyzivat <[email-masked]> wrote:
> 
> I primarily think of months by name rather than number.

Other people think of months by number…

> So every time I read a date with numeric month I have to make a mental translation (however small) to put it in a form that I can comprehend.

… and need to make the translation from name.
(I’m pretty fast about this translation, so I don’t really care.)

I think there is some confusion about
(1) authoring documents with dates in them (RFCXML, authoring style)
(2) the prep-tool result (RFCXML, archival style)
(3) their presentation in plain text and HTML

The canonical form employed by (2) should be ISO 8601.
(1) can be flexible.
(3) really is the RFC editor style guide issue that we are discussing here.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Oct 2019 10:15:04 -0400

> ISO 8601 format across the board.

I find it amazing that it's not a given :-)

I concur.  PLEASE.

    > Intended status: Informational                                2019-10-01

Good.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 2 Oct 2019 10:25:24 -0400

> (3) really is the RFC editor style guide issue that we are discussing here.

So you are suggesting that I might be able to author documents using my 
preferred format, but they will eventually be rendered in an RFC using 
whatever format the style guide calls for?

I guess I would find it a halfway step if there was an xml element for 
entering a date, that accepts a variety of forms to suit the author, and 
then renders according to the style guide. But readability is what I am 
concerned with, and this wouldn't help that.

At the least, lets be sure that whatever is done here doesn't end up 
mangling figures, artwork, code, etc. where the format isn't negotiable.

It seems evident that I'm in the minority here, so having said my piece 
I guess I'll now shut up on this issue.

	Thanks,
	Paul

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 3 Oct 2019 11:50:41 +0200

Le 01/10/2019 à 23:10, Heather Flanagan a écrit :
> Hola a todos!
> 
> So, now that I have a new copy of draft-flanagan-7322bis out, I want
> to open up the floor for a particular discussion regarding date
> format. This has come up on the xml2rfc-dev list, but is something
> that should have a wider engagement.
> 
> - Month Year - Day Month Year - Month Day, Year
> 
> And in those options, sometimes there will be numerals for the day
> and/or the month, and sometimes not. We won’t discuss the variations
> in punctuation that may be involved, since that usually isn’t a
> problem in our typical use cases.
> 
> Reasons for it: * consistency within an RFC * sortable date logic
> 
> Reasons against it: * aesthetics (and with that, possible
> readability) * inconsistence with past RFCs
> 
> Network Working Group                                        H.
> Flanagan Internet-Draft
> S. Ginoza Obsoletes: 7322 (if approved)
> RFC Editor Intended status: Informational
> 2019-10-01 Expires: 2020-04-03 The Boilerplate text would look like: 
> No decisions have been made here (though you’ll see a mix of some of
> those date formats in 7322bis and in current xml2rfc outputs).
> Feedback is welcome!

2019-10-01 is so ugly looking (sorry, it is about the format).  The
appearance ugliness is accentuated by the ambiguities it potentially
introduces, making it also clumsy.

So situated might read as something of an ISBN or ISSN.

I would like to see it preceded by a word that tells that is the date;
something like 'date', or the word 'Today is', or 'Document issued on
date...'

RFCs are forever, which is forward, so it might need anchoring.  So one
might want to add the anchor of that year: 2019 times the Earth turned
around Sun since the birth of an influent person (AD - Anno Domini,
which might need disclaimers about religion).

The use of ISO format for date here is ambiguous to any reader knowing
this is a US style product, so you dont know whether it is October 1st
or January 10th.

ISO for date is coming with the risk similar of ISO style phone numbers
which present the same difficulty: local uses are stronger.

One might want to have clickable buttons that display the date according
to the Country style.  (inspired by EU law display).

Alex

> 
> -Heather
> 
> _______________________________________________ rfc-interest mailing
> list [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 3 Oct 2019 11:51:10 +0200

> version of the SINTRAN III operating system from Norsk Data ;-).

I thought before year 2000 the style '77 was preferred :-)

It's good to know they proposed to use 1977-05-17 rather than 77-05-17.
  I guess at that time that number could be confused with a phone number
and so they found better to disambiguate it.

This shortend style might come back as we get tired of typing and saying
20 each time.

It might happen at the respective time in the XXth century when people
got tired of saying 'nineteen' before saying the tens.  I suppose in
year 1902 people were still saying 'nineteen oh two', and not '2', but
as years passed by they started to say shorter 'fourty four' rather than
'nineteen fourty four', because the century number was supposed to be
there, err, long enough for one's lifetime.

Remark in French nobody said '19 44'; they actually said '1900 44', but
still they then shortened it to '44'.

The question is when will that shortening happen in XXIst century.

I suppose that at that time (maybe in year 2050?) people will start
again saying '50 rather than 2050, and that will become visible in
styles like '50-01-01' to mean January 1st of year 2050.

So, no, no abbreviated dates.  Rather: expanded dates.

Alex

> Regards Brian
>> it seems clear to me that we need to make an effort to make our 
>> choice readable not only to people who happen to use the same 
>> day/month/year element order we choose.
>> 
>> For this reason, I strongly advocate using month names rather than 
>> numbers, and using 4-digit years.  If this is done, it is possible 
>> to figure out the date that is meant even if it doesn't match the 
>> date format one is used to.
>> 
>> Most countries covered in 
>> https://en.wikipedia.org/wiki/Date_formats use either DMY or YMD 
>> order, so I'd suggest using either '1 October 2019' or '2019 
>> October 1' over 'October 1, 2019'.  Of those two, it seems to me 
>> that '1 October 2019' is the one most easily read.
>> 
>> 
>> Best regards,
>> 
>> Henrik
>> 
>>> So, now that I have a new copy of draft-flanagan-7322bis out, I 
>>> want to open up the floor for a particular discussion regarding 
>>> date format. This has come up on the xml2rfc-dev list, but is 
>>> something that should have a wider engagement.
>>> 
>>> And in those options, sometimes there will be numerals for the 
>>> day and/or the month, and sometimes not. We won’t discuss the 
>>> variations in punctuation that may be involved, since that 
>>> usually isn’t a problem in our typical use cases.
>>> 
>>> And probably a few more arguments either way.  Does the
>>> community have strong feelings about making a change? References
>>> (as an example) would look like this:
>>> 
>>> [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol 
>>> Core," IETF, RFC 3080, DOI 10.17487/RFC3080, 2011-03, 
>>> <https://www.rfc- editor.org/info/rfc3080>
>>> 
>>> [RFC-STYLE] Flanagan, H. and S.  Ginoza, "RFC Style Guide", Work 
>>> in Progress, Internet-Draft, draft-flanagan-style-04, 2019-10-01
>>> 
>>> Flanagan Internet-Draft S. Ginoza Obsoletes: 7322 (if approved) 
>>> RFC Editor Intended status: Informational 2019-10-01 Expires:
>>> 2020-04-03 The Boilerplate text would look like: This
>>> Internet-Draft will expire on 2020-04-03.
>>> 
>>> No decisions have been made here (though you’ll see a mix of
>>> some of those date formats in 7322bis and in current xml2rfc
>>> outputs). Feedback is welcome!
>>> 
>>> -Heather
>>> 
>>> _______________________________________________ rfc-interest 
>>> mailing list [email-masked] 
>> _______________________________________________ rfc-interest 
>> mailing list [email-masked]

---

From: "John Levine" <[email-masked]>
Date: 3 Oct 2019 15:16:08 -0400

>quite certain that I don't want to inflict pure numeric dates on readers.

I suspect the most widely used date format in IETF standards is the
one in RFCs 822, 2822, and 5322, for headers in e-mail messages.
You'll see it in Date:, Received: and other more obscure places.

It's "dd Mon yyyy" where Mon is a three letter month abbreviation.

R's,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 4 Oct 2019 08:18:08 +1300

> It's good to know they proposed to use 1977-05-17 rather than 77-05-17.

Actually, not, the formal designation of that software release was 770517C.
(It is engraved on my memory since it was the main focus of my job for several
years.) I thought I would not confuse the discussion with the Y2K problem or
the cosmetic hyphens.

I do agree with you that 2019-10-04 is a little ugly, but we have an 
international readership and English is the 2nd or 3rd language for many.
So an unambiguous and language-independent format seems right.

    Brian

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 3 Oct 2019 16:57:55 -0400

> It's "dd Mon yyyy" where Mon is a three letter month abbreviation.

Sadly, strftime(3) and friends do not portably emit RFC822 dates.
If I set my locale to "ru_RU.UTF-8", on FreeBSD 12 I get:

    $ LANG=ru_RU.UTF-8 date +"%a, %e %b %Y %H:%M:%S %z"
    чт,  3 окт. 2019 16:41:54 -0400

and the documentation makes no mention of any "%" expansions that
unconditionally yield "Thu" and "Oct", regardles of the locale.

However "unfriendly", I find ISO numeric dates much more usable,
they sort properly (within a given timezone, especially UTC) and
are portable and unambiguous:

    $ for l in en_US.UTF-8 ru_RU.UTF-8; do LANG=$l date +"$l: %Y-%m-%dT%H:%M:%S%z"; done
    en_US.UTF-8: 2019-10-03T16:56:00-0400
    ru_RU.UTF-8: 2019-10-03T16:56:00-0400

-- 
	Viktor.

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 6 Oct 2019 17:44:36 +0200

> However "unfriendly", I find ISO numeric dates much more usable,

I am not against the consensus.  I discuss.

>      ru_RU.UTF-8: 2019-10-03T16:56:00-0400

This is good to know, thank you.  I understand that even a Russian 
format seems to issue same date output, even as Russian might seem from 
English.

But, if one wants to consider a truly Russian style, then one would like 
to see first an operating system that is originated from the grounds up 
(from assembler up, like even the instruction mnemonics would be 
Russian, not English MV for 'move') from Russian.  You would need to see 
a programming language that does not say 'if' but says 'esli', or other 
Russian word for 'if'.  Then, un such an environment, one would like to 
see how they say the date format, and whether the anchoring (year 0) is 
he same.

Hopefully suh a system would have TCP/IP on it and its specs written in 
Russian.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 9 Oct 2019 17:07:04 +0200

I wanted to say that, if I remember correctly, in Russian people add a 
'g' sticked on the number of the year, to mean 'year' ('god', ru.).

I think that is more helpful for the reader.

Alex

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 9 Oct 2019 15:28:39 -0400

> format seems to issue same date output, even as Russian might seem from 

The whole point is that ISO dates are a "cold" format somewhat
detached from cultural traditions, appealing to semantics (good
lexical ordering), rather than aesthetics (cultural baggage).

Yes, ISO dates use a "Western" calendar, and the digits are Western
numerals with a "T" separator that is mnemonic in English and French,
from Latin "Tempus", and not German "Zeit", Russian "Время" or
Hebrew "זמן".  And yet the choice is about as "international" as
is practically possible.