The semantics of milliseconds, microseconds, and nanoseconds properties are not clear from their names because there are multiple possible interpretations.
microseconds whether the higher unit is "seconds" or "milliseconds" and not clear for nanoseconds whether the higher unit is "seconds" or "milliseconds" or "microseconds".This _could_ be addressed solely by documentation, but I'd like to see something better. There is an analogous problem with days (i.e., day-of-week vs. day-of-month vs. day-of-year) that is solved by explicit naming (i.e., dayOfWeek vs. day vs. dayOfYear), and I think either the same approach should be used here (e.g., wholeMillisecondsOfSecond, wholeMicrosecondsOfMillisecond, wholeNanosecondsOfMicrosecond) or the intermediate fractional units should be dropped such that there is nothing between second and nanosecond (in which case the constructors should probably also be updated accordingly).
I think the confusion came after introducing microsecond, which I think is over-engineering.
before that, the mental-model is simply millisecond and sub-millisecond (nanosecond)
there is significant js-ecosystem dependent on millisecond precision, so that's not going away (unless we want another community-schism like es-modules v. commonjs). i prefer the solution:
millisecondsOfSecond and nanosecondsOfMillisecondrealistically, who would enjoy working on sub-millisecond arithmetic requiring further breakdown between microsecond and nanosecond? i certainly wouldn't.
@pipobscure @sffc @maggiepint what do you all think about this?
I don't have a sense of what the implications are for users of Temporal of having different fields for millisecond, microsecond, and nanosecond. I can see conceptual advantages to the current approach, and this thread has some good points that suggest maybe an alternative approach is better.
/cc @mj1856 perhaps you could chime in too? What do you think about this?
I think this is important, because having separate fields this way allows for comfortable arbitrary precision usage.
(I鈥檓 on the road now. More detailed comments later)
For the record, I feel much better about the current state of the proposal, in which every non-$unitOf$unit field represents an integer-valued offset in the next-larger calendar date鈥搕ime unit and only Duration uses plural-named fields. I believe this issue has been satisfactorily addressed, and now consider it resolved.
Great! I鈥檓 happy this reached a satisfactory settlement. Closing this, but feel free to reopen if you feel otherwise.