Messages - Use ISO 8601:2004 date for UserInfo.birthday?

[Vladimir Dzhuvinov]

The UserInfo birthday claim uses a MM/DD/YYYY format at present.

My proposal is to use standard ISO-8601 date formatting instead. The updated_time claim already uses ISO-8601 and this would make date/time representation in UserInfo claims more consistent.

[Former user]

Which in short means that dates should be represented as YYYY-MM-DD

My personal preference would be for StarDate (http://en.wikipedia.org/wiki/Stardate) which unfortunately has not been successfully standardized :) Given this, I think ISO-8601 is a reasonable compromise.

FTR, Google's userinfo implementation (not yet openid-connect compliant) is currently 8601-compliant.

[Vladimir Dzhuvinov]

We're not there yet ;-)

What is a reasonable way to represent an ISO-8601 date when the user has chosen not to share their year of birth? 0000 as it is now? Or YYYY-MM?

[Michael Jones]

Nat will read ISO-8601 and investigate whether we can use 0000 as the year in the way proposed.

[Nat Sakimura]

Strictly speaking, No. 0000 is year 0. Quoting from ISO 8601:2004

calendar year is, unless specified otherwise, represented by four digits. Calendar years are numbered in ascending order according to the Gregorian calendar by values in the range [0000] to [9999]. Values in the range [0000] through [1582] shall only be used by mutual agreement of the partners in information interchange.

Furthermore, ISO 8601:2004 does not define any way of representing just month and day.

The problem is that if we write 12-04, we do not know whether it is 2012-04 or December 4th of some year. There are delimiters Y, M, D defined in ISO 8601:2004, so perhaps we can extend the standard to represent December 4th as 12M04D, but it is illegal in ISO 8601, I think, and requires two path in the parser.

One way to deal with it is to leverage on the "Values in the range [0000] through [1582] shall only be used by mutual agreement of the partners in information interchange." We just agree that 0000 in this community specifies undefined year. (I think it still is illegal.)

The problem of this approach is that then there will be no way of expressing the birthday of someone born in BC1, like Ptolemy of Mauretania. Using 9999 instead may be better in this respect, as there is no one yet born for year 9999, and we still have over 7000 years to deal with.

[Casper Biering]

Is it the general persuasion that having just YYYY should be treated as the user/idp only sharing birthyear (as the oppsite to only sharing month and day).

I don't know if this generally will be treated well by datetime-parsing libraries, which might mistake it for YYYY-01-01 or something else. PHP's DateTime library seem to parse 2012 as 2012-06-01. We might add a note mentioning this.

ISO 8601:2004 allow for both YYYYMMDD and YYYY-MM-DD as valid formats. Just to be sure, we expect all receiving parties to support both?

[Nat Sakimura]

I think we should profile ISO 8601:2004 further to state that YYYY-MM-DD as the format.

The specific text proposal is as follows:

birthday	string	The End-User's birthday, represented as an ISO 8601:2004 YYYY-MM-DD format. The year MAY be 9999, indicating that it is omitted. To represent only the year, YYYY format is allowed. Note that depending on the underlying platform's date related function, providing just year may result in varying month and day, so the implementors should take this factor into account to correctly process the dates. 

BTW, this is a breaking change.

[Michael Jones]

We agreed to change the claim name to "birthdate", allowing proprietary use of "birthday" with the old format.

[Nat Sakimura]

Fix #597 - Messages: Changed birthday to birthdate and made it ISO 8601:2004 format.

→ 12c6e299d9b1

[Nat Sakimura]

Issue #764 was marked as a duplicate of this issue.

[Nat Sakimura]

Michael Jones: We currently use "9999" as the year in the "birthdate" claim to indicate that the year was not provided. Facebook and Google's other OAuth APIs use "0000" for this. I think we'll cause less developer confusion and bugs if we do the same.

Michael Jones: We will tentatively change back to 0000 to match existing practice. Vladimir's input is requested first, since he filed the original bug requesting us to use 9999.

[Vladimir Dzhuvinov]

I reread Nat's comments. Then I had a look at ISO_8601-2004, section 4.1.2.1. The standard treats 9999 as a regular year. The years in the range 0000 through 1582 should not be communicated unless there's a mutual agreement. So using 0000 instead of 9999 seems to be a good choice indeed.

[Nat Sakimura]

Sold. Use 0000 instead.

[Michael Jones]

Fixed #597 - Changed representation of omitted year in "birthdate" from "9999" to "0000"

→ <<cset 0b4283f71111>>