Proposal: Duration

Alexandre Morgaut alexandre.morgaut at
Tue Mar 5 11:52:41 UTC 2019

Ron, Gus, Isiah,

Thank you for your interest and for pointing to the temporal proposal.
I'm happy to see it is already in stage 2, and be happy to contribute with
my humble experiences.

And yes Duration has its usage on its own independently to dates, but
date operation results are often expected to work with durations

I'm not sure to be fan of their name but:

   - I like CivilDate allowing to manage dates like January 1st, or
   birthdays independently from the timezone
   - Idem with CivilTime, handling midnight/noon or shop opening hours like
   seven / eleven can be very handy

I see you also want to fix Date 0-based month & week days
I know the JS Date object was inspired from a Java API which was later
deprecated so I understand the work going on here
I just find it very ambitious (in the Java case it was deprecated very

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
But well calendar usages are not only a question of regions but also of
cultures & periods...
The hard thing when we want to provide Date & Time APIs is that some
calendars are using other units than months or hours
But well, programming languages need standards so international date &
calendar have to rule here*
* unless we provide a very generic API with methods like "add(value,
unit)", but it can quickly become a nightmare
Then Calendar APIs may come with their own Date / Time APIs, supporting
related units, leap months, leap years and so on.


> 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...?

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.
And the "between()" API is just one usage of Durations


Sure that if Duration can take place there in the temporal proposal, it
could save it stage 0 & 1 ;-)
My only "fear" is that this proposal, while very interesting, is already
huge and I would not want both proposals to slow each other.
But if the TC39 team is confident let's jump in the train :-)

I'll start by updating my own repository to reference the temporal proposal.

One of my initial wonderings was "Where should we put the balance between
the domain coverage & API affordance?".

- The mentioned Java API doesn't cover the use case I mentioned in it's
between API. Should we care about it?
- Should we offer a single Duration object to cover the main concept or
provide a whole set of variant (TimeInterval, DateInterval, Period,
- Should we handle very high precision or large time units (nanoseconds,
microseconds, centuries... )
  - independently to the values the system can provide

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.
But I'm very open to more complete solutions

Le mar. 5 mars 2019 à 02:25, Isiah Meadows <isiahmeadows at> a
écrit :

> Alexandre: I feel it's only *related* to dates and times:
> - Dates and times refer to absolute points.
> - Durations would refer to distances between two dates and/or times.
> However, I do feel this should be discussed in
> And down this vein, I've
> created just now.
> Naveen: If you look at that proposal and particularly the issue I
> filed, you can see date handling isn't as simple as it looks. There's
> an entire database dedicated to localizing just times [1] (source:
> [2]), and numeric date handling is a mess all on its own, [3] even if
> you just stick with *just* the Gregorian calendar. [4] About the only
> portable way to handle a date is to just do a bunch of UTC offsets to
> the start of January 1, 1970, but even that has glitches in the form
> of leap seconds. [5]
> Or to put it simply: Date handling is hard.
> [1]:
> [2]:
> [3]:
> [4]:
> [5]:
> -----
> Isiah Meadows
> contact at
> On Mon, Mar 4, 2019 at 4:30 PM Mark Davis ️ <mark at> wrote:
> >
> > 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.
> >
> > Mark
> >
> >
> > On Mon, Mar 4, 2019 at 11:21 AM Naveen Chawla <naveen.chwl at>
> wrote:
> >>
> >> I don't like it. Duration is just milliseconds for me.
> >>
> >> On Mon, 4 Mar 2019 at 18:47 Alexandre Morgaut <
> alexandre.morgaut at> wrote:
> >>>
> >>> Here a proposal to make ECMAScript natively support a Duration Object
> >>>
> >>> I talked about it a long time ago (2011) on the WHATWG mailing list in
> the context of the Timers API:
> >>>
> >>> 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.
> >>>
> >>> ECMAScript natively support Dates since its very first version
> >>> It started to support the ISO 8601 string format in edition 5
> >>> ( Date Time String Format )
> >>>
> >>> 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.
> >>>
> >>> Duration, sometimes called TimeInterval, is a common concept supported
> by most languages or associated standard libs.
> >>>
> >>> In very short, Duration object would:
> >>> - support the ISO syntax in its contructor: new Duration('P6W') //
> for  Period 6 Weeks
> >>> - allow to handle Date diff operations
> >>> - allow to be interpreted by setTimeout() & setInterval()
> >>>
> >>> Please find below a draft exposing the concept
> >>> I'd be very happy if someone from TC39 would be interested to champion
> it
> >>>
> >>>
> >>> Regards,
> >>>
> >>> Alexandre.
> >>> _______________________________________________
> >>> es-discuss mailing list
> >>> es-discuss at
> >>>
> >>
> >> _______________________________________________
> >> es-discuss mailing list
> >> es-discuss at
> >>
> >
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list