<div dir="ltr"><div dir="ltr">Ron, Gus, Isiah,<div><br></div><div>Thank you for your interest and for pointing to the temporal proposal.</div><div>I'm happy to see it is already in stage <span class="gmail-gr_ gmail-gr_29 gmail-gr-alert gmail-gr_gramm gmail-gr_inline_cards gmail-gr_run_anim gmail-Punctuation gmail-only-del gmail-replaceWithoutSep" id="gmail-29" style="display:inline;border-bottom:2px solid transparent;background-repeat:no-repeat;color:inherit;font-size:inherit">2,</span> and be happy to contribute with my humble experiences.</div><div><br></div><div>And yes Duration has its usage on its own independently to dates, but date operation results are often expected to work with durations</div><div><br></div><div>I'm not sure to be <span class="gmail-gr_ gmail-gr_151 gmail-gr-alert gmail-gr_gramm gmail-gr_inline_cards gmail-gr_run_anim gmail-Grammar gmail-only-ins gmail-replaceWithoutSep" id="gmail-151" style="display:inline;border-bottom:2px solid transparent;background-repeat:no-repeat;color:inherit;font-size:inherit">fan</span> of their name but:</div><div><ul><li>I like CivilDate allowing to manage dates like January 1st, or birthdays independently from the timezone<br></li><li>Idem with <span class="gmail-gr_ gmail-gr_110 gmail-gr-alert gmail-gr_spell gmail-gr_inline_cards gmail-gr_disable_anim_appear gmail-ContextualSpelling gmail-ins-del gmail-multiReplace" id="gmail-110" style="display:inline;border-bottom:2px solid transparent;background-repeat:no-repeat;color:inherit;font-size:inherit">CivilTime</span>, handling <span class="gmail-gr_ gmail-gr_200 gmail-gr-alert gmail-gr_gramm gmail-gr_inline_cards gmail-gr_run_anim gmail-Style gmail-multiReplace" id="gmail-200" style="display:inline;border-bottom:2px solid transparent;background-repeat:no-repeat;color:inherit;font-size:inherit">midnight/noon</span> or shop opening hours like seven / eleven can be very handy<br></li></ul></div><div>I see you also want to fix Date 0-based month & <span class="gmail-gr_ gmail-gr_366 gmail-gr-alert gmail-gr_spell gmail-gr_inline_cards gmail-gr_run_anim gmail-ContextualSpelling gmail-ins-del" id="gmail-366" style="display:inline;border-bottom:2px solid transparent;background-repeat:no-repeat;color:inherit;font-size:inherit">week days</span></div><div>I know the JS Date object was inspired from a Java API which was later deprecated so I understand the work going on here</div><div>I just find it very ambitious (in the Java case it was deprecated very early)</div><div><br></div><div>I agree that the next challenge would be the handling of calendars, I think (my 2 cents) that it could make sense if most of the calendar job would take place in the Intl API</div><div>But well calendar usages are not only a question of regions but also of cultures & periods...</div><div>The hard thing when we want to provide Date & Time APIs is that some calendars are using other units than months or hours<br></div><div>ex: <a href="https://en.wikipedia.org/wiki/Chinese_units_of_measurement#Time">https://en.wikipedia.org/wiki/Chinese_units_of_measurement#Time</a></div><div>But well, programming languages need standards so international date & calendar have to rule here*</div><div>* unless we provide a very generic API with methods like "add(value, unit)", but it can quickly become a nightmare</div><div>Then Calendar APIs may come with their own Date / Time APIs, supporting related units, leap months, leap years and so on.</div><div><br></div><div><div><br class="gmail-Apple-interchange-newline">Naveen</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="color:rgb(0,0,0)">The problem here is that a "duration" of 2 months depends on the exact start date and timezone. So any "getMilliseconds" function would not be portable! So why not just stick with dates, and leave duration to be the difference in unix timestamp milliseconds between and 2 given dates?... This to me seems like the simplest way of handling all of this. Everyone do let me know if I'm missing anything...?</span></blockquote><br class="gmail-Apple-interchange-newline"><div>What you are missing, to my opinion, is that in some cases we really don't want to work with a milliseconds diff but with the real "number of months", or weeks, or days, especially if you are looking for periodicities.</div><div>And the "between()" API is just one usage of Durations</div><div><br></div></div><div>Now</div><div><br></div><div>Sure that if Duration can take place there in the temporal proposal, it could save it stage 0 & 1 ;-)</div><div>My only "fear" is that this proposal, while very interesting, is already huge and I would not want both <span class="gmail-gr_ gmail-gr_31 gmail-gr-alert gmail-gr_gramm gmail-gr_inline_cards gmail-gr_run_anim gmail-Grammar gmail-multiReplace" id="gmail-31" style="display:inline;border-bottom:2px solid transparent;background-repeat:no-repeat;color:inherit;font-size:inherit">proposals</span> to slow each other.</div><div>But if the TC39 team is confident let's jump in the train :-)</div><div><br></div><div>I'll start by updating my own repository to reference the temporal proposal.</div><div><br></div><div>One of my initial wonderings was "Where should we put the balance between the domain coverage & API affordance?".</div><div><br></div><div>Examples:</div><div>- The mentioned Java API doesn't cover the use case I mentioned in it's between API. Should we care about it?</div><div>- Should we offer a single Duration object to cover the main concept or provide a whole set of variant (TimeInterval, DateInterval, Period, Duration...)</div><div>- Should we handle very high precision or large time units (nanoseconds, microseconds, centuries... )</div><div>  - independently to the values the system can provide</div><div><br></div><div>My initial thoughts, to get it more easily accepted by the community, was to try to cover some complex but frequent usages while keeping the API as simple as possible.</div><div>But I'm very open to more complete solutions</div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mar. 5 mars 2019 à 02:25, Isiah Meadows <<a href="mailto:isiahmeadows@gmail.com">isiahmeadows@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Alexandre: I feel it's only *related* to dates and times:<br>
<br>
- Dates and times refer to absolute points.<br>
- Durations would refer to distances between two dates and/or times.<br>
<br>
However, I do feel this should be discussed in<br>
<a href="https://github.com/tc39/proposal-temporal" rel="noreferrer" target="_blank">https://github.com/tc39/proposal-temporal</a>. And down this vein, I've<br>
created <a href="https://github.com/tc39/proposal-temporal/issues/109" rel="noreferrer" target="_blank">https://github.com/tc39/proposal-temporal/issues/109</a> just now.<br>
<br>
Naveen: If you look at that proposal and particularly the issue I<br>
filed, you can see date handling isn't as simple as it looks. There's<br>
an entire database dedicated to localizing just times [1] (source:<br>
[2]), and numeric date handling is a mess all on its own, [3] even if<br>
you just stick with *just* the Gregorian calendar. [4] About the only<br>
portable way to handle a date is to just do a bunch of UTC offsets to<br>
the start of January 1, 1970, but even that has glitches in the form<br>
of leap seconds. [5]<br>
<br>
Or to put it simply: Date handling is hard.<br>
<br>
[1]: <a href="https://www.iana.org/time-zones" rel="noreferrer" target="_blank">https://www.iana.org/time-zones</a><br>
[2]: <a href="https://github.com/eggert/tz" rel="noreferrer" target="_blank">https://github.com/eggert/tz</a><br>
[3]: <a href="https://en.wikipedia.org/wiki/Calendar_date" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Calendar_date</a><br>
[4]: <a href="https://en.wikipedia.org/wiki/Gregorian_calendar" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Gregorian_calendar</a><br>
[5]: <a href="https://en.wikipedia.org/wiki/Leap_second" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Leap_second</a><br>
<br>
-----<br>
<br>
Isiah Meadows<br>
<a href="mailto:contact@isiahmeadows.com" target="_blank">contact@isiahmeadows.com</a><br>
<a href="http://www.isiahmeadows.com" rel="noreferrer" target="_blank">www.isiahmeadows.com</a><br>
<br>
<br>
On Mon, Mar 4, 2019 at 4:30 PM Mark Davis ️ <<a href="mailto:mark@macchiato.com" target="_blank">mark@macchiato.com</a>> wrote:<br>
><br>
> Sadly, time is not that simple. Most people using calendars consider the duration between January 15 and March 15 to be exactly 2 months. But such intervals are a different number of days, hence milliseconds.<br>
><br>
> Mark<br>
><br>
><br>
> On Mon, Mar 4, 2019 at 11:21 AM Naveen Chawla <<a href="mailto:naveen.chwl@gmail.com" target="_blank">naveen.chwl@gmail.com</a>> wrote:<br>
>><br>
>> I don't like it. Duration is just milliseconds for me.<br>
>><br>
>> On Mon, 4 Mar 2019 at 18:47 Alexandre Morgaut <<a href="mailto:alexandre.morgaut@gmail.com" target="_blank">alexandre.morgaut@gmail.com</a>> wrote:<br>
>>><br>
>>> Here a proposal to make ECMAScript natively support a Duration Object<br>
>>><br>
>>> I talked about it a long time ago (2011) on the WHATWG mailing list in the context of the Timers API: <a href="https://lists.w3.org/Archives/Public/public-whatwg-archive/2011Feb/0533.htm" rel="noreferrer" target="_blank">https://lists.w3.org/Archives/Public/public-whatwg-archive/2011Feb/0533.htm</a><br>
>>><br>
>>> l think that such a proposal would better take place in the core of the language and having worked on a framework date time APIs I tried to give this approach a better look.<br>
>>><br>
>>> ECMAScript natively support Dates since its very first version<br>
>>> It started to support the ISO 8601 string format in edition 5<br>
>>> (15.9.1.15 Date Time String Format )<br>
>>><br>
>>> Durations like Dates can be very tricky, especially with I18n in mind, but the ECMA standard already had to be handled most of the Duration tricky part for the Date Object in EMCA 262 & ECMA 402.<br>
>>><br>
>>> Duration, sometimes called TimeInterval, is a common concept supported by most languages or associated standard libs.<br>
>>><br>
>>> In very short, Duration object would:<br>
>>> - support the ISO syntax in its contructor: new Duration('P6W') // for  Period 6 Weeks<br>
>>> - allow to handle Date diff operations<br>
>>> - allow to be interpreted by setTimeout() & setInterval()<br>
>>><br>
>>> Please find below a draft exposing the concept<br>
>>> I'd be very happy if someone from TC39 would be interested to champion it<br>
>>> <a href="https://github.com/AMorgaut/proposal-Duration" rel="noreferrer" target="_blank">https://github.com/AMorgaut/proposal-Duration</a><br>
>>><br>
>>> Regards,<br>
>>><br>
>>> Alexandre.<br>
>>> _______________________________________________<br>
>>> es-discuss mailing list<br>
>>> <a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
>>> <a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
>><br>
>> _______________________________________________<br>
>> es-discuss mailing list<br>
>> <a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
>> <a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
><br>
> _______________________________________________<br>
> es-discuss mailing list<br>
> <a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
> <a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div>