Discuss
  • Proposal: Duration

Proposal: Duration

# Alexandre Morgaut (6 years ago)

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: lists.w3.org/Archives/Public/public-whatwg-archive/2011Feb/0533.htm

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 (15.9.1.15 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 AMorgaut/proposal-Duration

,

Alexandre.

# Naveen Chawla (6 years ago)

I don't like it. Duration is just milliseconds for me.

# Ron Buckton (6 years ago)

Personally, I’d love to see something like this included as part of the temporal proposal (tc39/proposal-temporal), as I’ve been experimenting with something very much like this here: rbuckton/temporal/blob/master/src/Duration.ts.

I think a Duration type that meshes with the proposed plus method on temporal objects would be a huge benefit.

Ron

From: es-discuss <es-discuss-bounces at mozilla.org> On Behalf Of Alexandre Morgaut

Sent: Monday, March 4, 2019 10:47 AM To: es-discuss list <es-discuss at mozilla.org>

Subject: Proposal: Duration

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: lists.w3.org/Archives/Public/public-whatwg-archive/2011Feb/0533.htmnam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.w3.org%2FArchives%2FPublic%2Fpublic-whatwg-archive%2F2011Feb%2F0533.htm&data=02|01|ron.buckton%40microsoft.com|b2fcb78ce9714918767e08d6a0d1d84f|72f988bf86f141af91ab2d7cd011db47|1|0|636873220570122388&sdata=bkZ0jPGkuKT3a35let3ZFVXrk2oq%2FeLzKN7xcuR1ym0%3D&reserved=0

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 (15.9.1.15 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 AMorgaut/proposal-Durationnam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAMorgaut%2Fproposal-Duration&data=02|01|ron.buckton%40microsoft.com|b2fcb78ce9714918767e08d6a0d1d84f|72f988bf86f141af91ab2d7cd011db47|1|0|636873220570132397&sdata=JJiv%2BitghIjSomxEuyT5Yic7IWrpSTBwmYWmBBnduUU%3D&reserved=0

,

Alexandre.

# Mark Davis ☕️ (6 years ago)

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

# Gus Caplan (6 years ago)

Please take a look at tc39/proposal

# Isiah Meadows (6 years ago)

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 tc39/proposal-temporal. And down this vein, I've created tc39/proposal-temporal#109 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.

Isiah Meadows contact at isiahmeadows.com, www.isiahmeadows.com

# Alexandre Morgaut (6 years ago)

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 early)

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 ex: en.wikipedia.org/wiki/Chinese_units_of_measurement#Time 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.

Naveen

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

Now

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

Examples:

  • 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, Duration...)
  • 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 gmail.com> a écrit :