DateTime entry point data

[zbraniecki]

For the initial release of DateTimeFormat, we'd like to ensure that we understand what data we'd like the future DateTime struct to provide.

For 0.1 release my plan is to include some DummyDateTime or MockDateTime as part of icu-datetime crate which will be a very minimal mock, but with the right information.

This will allow us to present the formatter and enable the Rust community to work on date/time management API that will contain the correct data we need to format it properly.

In particular, @sffc pointed out that we'll likely want the calendar information to be included.

[zbraniecki]

@sffc:

An interesting question is going to be how we represent the rest of the fields: weekday, all three kinds of day period, era, and so forth.

[zbraniecki]

In #301 I'm renaming away from Dummy.

@sffc said he wants to write a short doc about trait and struct considerations for future implementers of a concrete type.

I'd like to ask @nciric @mihnita and @sffc to also review https://github.com/unicode-org/icu4x/blob/master/components/datetime/src/date.rs#L33-L40 and let me know what changes they'd like to see in the type for 0.1.

I will add them with unimplemented!() to communicate the scope of the API we expect others to implement.

@mihnita brought up milliseconds which I'll add, and @sffc mentioned calendars, but I'm not sure how they should be expressed in such mock type.
Anything else?

[mihnita]

I think that calendar info is needed, probably timezone.

A DateTime class without calendar info is like a currency expressed as in integer (without the currency code)
:-)

I think that the ECMAScript Temporal is a good model.

But it is a bit too complex to try to capture for 0.1 (there is Instant, Date, Time, DateTime, ZonedDateTime, YearMonth, MonthDay, TimeZone, Calendar, etc)
And it is not the job of ICU4X to do that anyway.

For us, if we add info on calendar and timezone (and millisecond), all in the MockDateTime class, I think we are fine.

Data types (Shane?): calendar & timezone will probably need to be classes, with strings for id.
But we can use string for now? ("conflate" the class with the ID, "pretending" that the class is some implementation detail, not exposed in the public APIs)

Making them directly classes would means that we are betting that this is the direction Rust will go, when it gets to solving this problem. And we don't know that.

[zbraniecki]

We ended up working on two documents.

Shane is working on a more detailed explanation for the requirements for the API, while I wrote a shorter "intro" doc for the Rust community to the problem scope and the role of ICU4X in it - https://github.com/unicode-org/icu4x/wiki/Rust-Date-and-Time-API-Request

My doc will be updated to link to Shane's.

[zbraniecki]

Feel free to edit and adjust the wiki as needed @mihnita @sffc and others :)

[zbraniecki]

Shane added https://github.com/unicode-org/icu4x/blob/master/docs/datetime-input.md .

With those two, I consider it done!