Why do we care about the input value's type? Are these not implementation concerns?

These are implementation concerns. But they generate requirements for date/time formatting options.

Really? Could you give an example, because I don't see how.

One such problem is the need to manage an input value's relationship to the timeline. While temporal types trying to pack all of the information into strongly typed objects, classical time values are usually timestamps (seconds or millis of epoch time). Formatting them requires a time zone (or at least an offset). Which means some external way of expressing the zone when it is different from the runtime's default time zone.

Delivery time local to you and not this web server will be: {$timestamp :datetime timezone=$usersTimeZone}

There is also a need to be able to "float" a value: remove it from the timeline so that field values stay constant regardless of time zone. This involves removing the time zone from the value, the equivalent of ZonedDateTime.toLocalDateTime() in Java:

Your birthday is: {$birthday :datetime offset=none} (option name made up on the spot)

Again, isn't this an implementation concern? I don't see what this has to do with the shape of the formatting options.

This is one of the main benefits of the semantic skeleton design, and I think points 1-4 can all be merged into this one. The point is that not all date types are the same and not all formatters are the same, and the date type needs to be able to expose all fields that the formatter needs.

Are dateFields, date and fields just different possible names for the same option? Or do they mean different things? (Same question about timePrecision vs. time below.)

Different possible names for the same option.

I think this needs a little more explanation (it should be possible to follow this doc without reading the other linked-to docs).

This part of the spec is basically empty and in need of work. I started to noodle around with it today. Each one of the options will need quasi-complete descriptions in order to see how they'll work and the relative usability of each.

I want to be more clear about what is "required" versus "wanted".

I think "required" is that users should specify an overall length, and "wanted" to hint at the width of an individual field independently of the overall length.

But only 1 more than the previous option. The only one this adds is :zoneddatetime.

Great, so if naming is the only problem here, let's bikeshed the names and make another set of names. Let's try not to deviate too much from java.time and Temporal. :)

You mean like java.time and JS Temporal just did with Local vs. Plain? 🤣

Let's not overlook the fact that lots of platforms still don't have temporal types for date/time values. And that platforms that do have temporal types also have timestamps and classical time values that require formatting. The problem I'm calling out here is absolutely about bikeshedding the names/options--in order to ensure that we get the most usable syntax in MF. That shouldn't deviate one whit from what our Java/JS friends (who are mostly us after all) have done, except to make the concepts portable.

I don't understand the relevance of this. Isn't this purely an implementation concern, which has no visibility in the MF2 syntax? As I understand it, the idea is for the function names to describe the formatted output, not the input.

A reasonable approach would be to name the functions consistent with usage. The point here is that there is not agreement on what to call these.

I still don't understand how naming concerns about an input value type would transmit to the syntax. For example, I would expect an expression for a time with hours and minutes to look something like

{$t :datetime hour=numeric minute=numeric}

or maybe

{$t :time fields=hm}

irrespective of whether $t held a floating time value, or one with a timezone attached, or any other representation of the value to be formatted.

Or do you think we ought to have different functions for each input datetime type supported by an implementation?

This is capturing some of the conversation in Monday's call. Ultimately this isn't the place for it.

Some people, such as @sffc, have expressed a desire for the functions to be "type safe". This might mean naming functions for the the underlying behavior, e.g. :localdate or :localtime--- s/local/[civil|plain|...]/g

By "type safe" I mean that there should be well-defined semantics around when implementations should emit a Bad Operand error. For example, if you pass an implementation-specific "time-only" type to :date, you should get a Bad Operand error.