Consider date formatting

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Consider date formatting

Michael Kriegel
I would like to suggest to take up date formatting into the standard.
Either as optional format parameter on Date.prototype.toDateString() or
as a separate method Date.prototype.toFormattedDateString(format).

format should be a string in the form as specified in
https://tc39.github.io/ecma262/#sec-date-time-string-format

I know there are libraries for that, but I think it is fundamental
enough to put it into the standard instead.

I hope this was not already discussed before and I just did not find the
thread.

--
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • +41 56 250 40 02


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Consider date formatting

kdex
So what's wrong with Intl.DateTimeFormat?

On Thursday, September 21, 2017 8:41:33 AM CEST Michael Kriegel wrote:

> I would like to suggest to take up date formatting into the standard.
> Either as optional format parameter on Date.prototype.toDateString() or
> as a separate method Date.prototype.toFormattedDateString(format).
>
> format should be a string in the form as specified in
> https://tc39.github.io/ecma262/#sec-date-time-string-format
>
> I know there are libraries for that, but I think it is fundamental
> enough to put it into the standard instead.
>
> I hope this was not already discussed before and I just did not find the
> thread.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Consider date formatting

Michael Kriegel

You cannot set an arbitrary format. From a UI point of view it is great to format it "localized", but if you have strict requirements in your projects, then you have to build it up yourself or use a library. So I do not see, how to use Intl.DateTimeFormat for custom format strings.


On 21.09.2017 08:45, kdex wrote:
So what's wrong with Intl.DateTimeFormat?

On Thursday, September 21, 2017 8:41:33 AM CEST Michael Kriegel wrote:
I would like to suggest to take up date formatting into the standard.
Either as optional format parameter on Date.prototype.toDateString() or
as a separate method Date.prototype.toFormattedDateString(format).

format should be a string in the form as specified in
https://tc39.github.io/ecma262/#sec-date-time-string-format

I know there are libraries for that, but I think it is fundamental
enough to put it into the standard instead.

I hope this was not already discussed before and I just did not find the
thread.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

-- 
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • +41 56 250 40 02

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Consider date formatting

kdex
You can build custom formats with
`Intl.DateTimeFormat.prototype.formatToParts`.

Combine these results with template literals; isn't that enough?

On Thursday, September 21, 2017 8:52:10 AM CEST Michael Kriegel wrote:

> You cannot set an arbitrary format. From a UI point of view it is great
> to format it "localized", but if you have strict requirements in your
> projects, then you have to build it up yourself or use a library. So I
> do not see, how to use Intl.DateTimeFormat for custom format strings.
>
> On 21.09.2017 08:45, kdex wrote:
> > So what's wrong with Intl.DateTimeFormat?
> >
> > On Thursday, September 21, 2017 8:41:33 AM CEST Michael Kriegel wrote:
> >> I would like to suggest to take up date formatting into the standard.
> >> Either as optional format parameter on Date.prototype.toDateString() or
> >> as a separate method Date.prototype.toFormattedDateString(format).
> >>
> >> format should be a string in the form as specified in
> >> https://tc39.github.io/ecma262/#sec-date-time-string-format
> >>
> >> I know there are libraries for that, but I think it is fundamental
> >> enough to put it into the standard instead.
> >>
> >> I hope this was not already discussed before and I just did not find the
> >> thread.
> >>
> >>
> >> _______________________________________________
> >> es-discuss mailing list
> >> [hidden email]
> >> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Consider date formatting

Michael Kriegel

Okay, this is still draft, I did not see it. It is very powerful, yet it makes it more complicated. The format strings, which are widely known and used would be handy to have in addition. However, if "they" decide, not to have them, I can still decide to use formatToParts or a library.


On 21.09.2017 08:56, kdex wrote:
You can build custom formats with 
`Intl.DateTimeFormat.prototype.formatToParts`.

Combine these results with template literals; isn't that enough?

On Thursday, September 21, 2017 8:52:10 AM CEST Michael Kriegel wrote:
You cannot set an arbitrary format. From a UI point of view it is great
to format it "localized", but if you have strict requirements in your
projects, then you have to build it up yourself or use a library. So I
do not see, how to use Intl.DateTimeFormat for custom format strings.

On 21.09.2017 08:45, kdex wrote:
So what's wrong with Intl.DateTimeFormat?

On Thursday, September 21, 2017 8:41:33 AM CEST Michael Kriegel wrote:
I would like to suggest to take up date formatting into the standard.
Either as optional format parameter on Date.prototype.toDateString() or
as a separate method Date.prototype.toFormattedDateString(format).

format should be a string in the form as specified in
https://tc39.github.io/ecma262/#sec-date-time-string-format

I know there are libraries for that, but I think it is fundamental
enough to put it into the standard instead.

I hope this was not already discussed before and I just did not find the
thread.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

-- 
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • +41 56 250 40 02

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Consider date formatting

Bob Myers
In reply to this post by Michael Kriegel
There are third-party libraries which are so widely-used as to be defacto standards.
Bob

On Thu, Sep 21, 2017 at 12:11 PM, Michael Kriegel <[hidden email]> wrote:
I would like to suggest to take up date formatting into the standard. Either as optional format parameter on Date.prototype.toDateString() or as a separate method Date.prototype.toFormattedDateString(format).

format should be a string in the form as specified in https://tc39.github.io/ecma262/#sec-date-time-string-format

I know there are libraries for that, but I think it is fundamental enough to put it into the standard instead.

I hope this was not already discussed before and I just did not find the thread.

--
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • +41 56 250 40 02


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Consider date formatting

Michael Kriegel

Quoting my initial posting:

> I know there are libraries for that, but I think it is fundamental enough to put it into the standard instead.

Isn't it legitimate to ask for a defacto-standard to become a real standard...


On 21.09.2017 09:13, Bob Myers wrote:
There are third-party libraries which are so widely-used as to be defacto standards.
Bob

On Thu, Sep 21, 2017 at 12:11 PM, Michael Kriegel <[hidden email]> wrote:
I would like to suggest to take up date formatting into the standard. Either as optional format parameter on Date.prototype.toDateString() or as a separate method Date.prototype.toFormattedDateString(format).

format should be a string in the form as specified in https://tc39.github.io/ecma262/#sec-date-time-string-format

I know there are libraries for that, but I think it is fundamental enough to put it into the standard instead.

I hope this was not already discussed before and I just did not find the thread.

--
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • +41 56 250 40 02


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


-- 
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • +41 56 250 40 02

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Consider date formatting

Matthew Robb
+1 this sentiment

Raise your hand if you are using Moment.js in projects today?
Raise your hand if you ship the library wholesale?
Raise your hand if you use webpack tok strip out the locale files which add sig. heft to your bundle?

Moment.js should be standardized...

HOWEVER: The language spec is likely the wrong place. This should probably be a browser spec as the biggest motivation is going to be localization which I find obnoxious to include in an often shipped defacto lib.


- Matthew Robb

On Thu, Sep 21, 2017 at 3:17 AM, Michael Kriegel <[hidden email]> wrote:

Quoting my initial posting:

> I know there are libraries for that, but I think it is fundamental enough to put it into the standard instead.

Isn't it legitimate to ask for a defacto-standard to become a real standard...


On 21.09.2017 09:13, Bob Myers wrote:
There are third-party libraries which are so widely-used as to be defacto standards.
Bob

On Thu, Sep 21, 2017 at 12:11 PM, Michael Kriegel <[hidden email]> wrote:
I would like to suggest to take up date formatting into the standard. Either as optional format parameter on Date.prototype.toDateString() or as a separate method Date.prototype.toFormattedDateString(format).

format should be a string in the form as specified in https://tc39.github.io/ecma262/#sec-date-time-string-format

I know there are libraries for that, but I think it is fundamental enough to put it into the standard instead.

I hope this was not already discussed before and I just did not find the thread.

--
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • <a href="tel:+41%2056%20250%2040%2002" value="+41562504002" target="_blank">+41 56 250 40 02


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


-- 
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • <a href="tel:+41%2056%20250%2040%2002" value="+41562504002" target="_blank">+41 56 250 40 02

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Consider date formatting

Isiah Meadows-2
In reply to this post by Michael Kriegel

I wouldn't quite call Moment and similar "de facto standards", especially not to the degree of something like Underscore/Lodash or Promises/A+ (especially Bluebird), which resulted in numerous obvious additions to the spec - ES5 function and array methods are nearly a clone of those in Underscore, and ES6 promises are a mix of RSVP.js and Bluebird (with implementations initially adapted from the latter). Async functions came after promise users immediately jumped all over `co` and later, Bluebird's `Promise.fromCoroutine`, in both Node and the browser.

As for existing work on dates (we all know they're broken), check out this proposal, currently stage 1: https://github.com/tc39/proposal-temporal. (It currently has no date parsing facilities, but ISO 8601 support is being considered.)


On Thu, Sep 21, 2017, 03:17 Michael Kriegel <[hidden email]> wrote:

Quoting my initial posting:

> I know there are libraries for that, but I think it is fundamental enough to put it into the standard instead.

Isn't it legitimate to ask for a defacto-standard to become a real standard...


On 21.09.2017 09:13, Bob Myers wrote:
There are third-party libraries which are so widely-used as to be defacto standards.
Bob

On Thu, Sep 21, 2017 at 12:11 PM, Michael Kriegel <[hidden email]> wrote:
I would like to suggest to take up date formatting into the standard. Either as optional format parameter on Date.prototype.toDateString() or as a separate method Date.prototype.toFormattedDateString(format).

format should be a string in the form as specified in https://tc39.github.io/ecma262/#sec-date-time-string-format

I know there are libraries for that, but I think it is fundamental enough to put it into the standard instead.

I hope this was not already discussed before and I just did not find the thread.

--
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • +41 56 250 40 02


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


-- 
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • +41 56 250 40 02
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Consider date formatting

Isiah Meadows-2

No, you're probably thinking of ECMA 404, which handles all the ES `Intl.*` stuff. It's still under the TC39 umbrella, just not part of ES proper.


On Thu, Sep 21, 2017, 09:14 Isiah Meadows <[hidden email]> wrote:

I wouldn't quite call Moment and similar "de facto standards", especially not to the degree of something like Underscore/Lodash or Promises/A+ (especially Bluebird), which resulted in numerous obvious additions to the spec - ES5 function and array methods are nearly a clone of those in Underscore, and ES6 promises are a mix of RSVP.js and Bluebird (with implementations initially adapted from the latter). Async functions came after promise users immediately jumped all over `co` and later, Bluebird's `Promise.fromCoroutine`, in both Node and the browser.

As for existing work on dates (we all know they're broken), check out this proposal, currently stage 1: https://github.com/tc39/proposal-temporal. (It currently has no date parsing facilities, but ISO 8601 support is being considered.)


On Thu, Sep 21, 2017, 03:17 Michael Kriegel <[hidden email]> wrote:

Quoting my initial posting:

> I know there are libraries for that, but I think it is fundamental enough to put it into the standard instead.

Isn't it legitimate to ask for a defacto-standard to become a real standard...


On 21.09.2017 09:13, Bob Myers wrote:
There are third-party libraries which are so widely-used as to be defacto standards.
Bob

On Thu, Sep 21, 2017 at 12:11 PM, Michael Kriegel <[hidden email]> wrote:
I would like to suggest to take up date formatting into the standard. Either as optional format parameter on Date.prototype.toDateString() or as a separate method Date.prototype.toFormattedDateString(format).

format should be a string in the form as specified in https://tc39.github.io/ecma262/#sec-date-time-string-format

I know there are libraries for that, but I think it is fundamental enough to put it into the standard instead.

I hope this was not already discussed before and I just did not find the thread.

--
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • +41 56 250 40 02


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


-- 
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • +41 56 250 40 02
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Consider date formatting

Michael Kriegel
In reply to this post by Matthew Robb

Actually I used it in node.js today - where using/deploying another lib is less "painful" - agreed. Still I don't think it is browser scope only...


On 21.09.2017 14:59, Matthew Robb wrote:
+1 this sentiment

Raise your hand if you are using Moment.js in projects today?
Raise your hand if you ship the library wholesale?
Raise your hand if you use webpack tok strip out the locale files which add sig. heft to your bundle?

Moment.js should be standardized...

HOWEVER: The language spec is likely the wrong place. This should probably be a browser spec as the biggest motivation is going to be localization which I find obnoxious to include in an often shipped defacto lib.


- Matthew Robb

On Thu, Sep 21, 2017 at 3:17 AM, Michael Kriegel <[hidden email]> wrote:

Quoting my initial posting:

> I know there are libraries for that, but I think it is fundamental enough to put it into the standard instead.

Isn't it legitimate to ask for a defacto-standard to become a real standard...


On 21.09.2017 09:13, Bob Myers wrote:
There are third-party libraries which are so widely-used as to be defacto standards.
Bob

On Thu, Sep 21, 2017 at 12:11 PM, Michael Kriegel <[hidden email]> wrote:
I would like to suggest to take up date formatting into the standard. Either as optional format parameter on Date.prototype.toDateString() or as a separate method Date.prototype.toFormattedDateString(format).

format should be a string in the form as specified in https://tc39.github.io/ecma262/#sec-date-time-string-format

I know there are libraries for that, but I think it is fundamental enough to put it into the standard instead.

I hope this was not already discussed before and I just did not find the thread.

--
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • <a href="tel:+41%2056%20250%2040%2002" value="+41562504002" target="_blank" moz-do-not-send="true">+41 56 250 40 02


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


-- 
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • <a href="tel:+41%2056%20250%2040%2002" value="+41562504002" target="_blank" moz-do-not-send="true">+41 56 250 40 02

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



-- 
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • +41 56 250 40 02

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Consider date formatting

Matthew Robb
I just mean to say that it makes more sense as a userland lib outside of the context of browsers.


- Matthew Robb

On Thu, Sep 21, 2017 at 9:35 AM, Michael Kriegel <[hidden email]> wrote:

Actually I used it in node.js today - where using/deploying another lib is less "painful" - agreed. Still I don't think it is browser scope only...


On 21.09.2017 14:59, Matthew Robb wrote:
+1 this sentiment

Raise your hand if you are using Moment.js in projects today?
Raise your hand if you ship the library wholesale?
Raise your hand if you use webpack tok strip out the locale files which add sig. heft to your bundle?

Moment.js should be standardized...

HOWEVER: The language spec is likely the wrong place. This should probably be a browser spec as the biggest motivation is going to be localization which I find obnoxious to include in an often shipped defacto lib.


- Matthew Robb

On Thu, Sep 21, 2017 at 3:17 AM, Michael Kriegel <[hidden email]> wrote:

Quoting my initial posting:

> I know there are libraries for that, but I think it is fundamental enough to put it into the standard instead.

Isn't it legitimate to ask for a defacto-standard to become a real standard...


On 21.09.2017 09:13, Bob Myers wrote:
There are third-party libraries which are so widely-used as to be defacto standards.
Bob

On Thu, Sep 21, 2017 at 12:11 PM, Michael Kriegel <[hidden email]> wrote:
I would like to suggest to take up date formatting into the standard. Either as optional format parameter on Date.prototype.toDateString() or as a separate method Date.prototype.toFormattedDateString(format).

format should be a string in the form as specified in https://tc39.github.io/ecma262/#sec-date-time-string-format

I know there are libraries for that, but I think it is fundamental enough to put it into the standard instead.

I hope this was not already discussed before and I just did not find the thread.

--
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • <a href="tel:+41%2056%20250%2040%2002" value="+41562504002" target="_blank">+41 56 250 40 02


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


-- 
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • <a href="tel:+41%2056%20250%2040%2002" value="+41562504002" target="_blank">+41 56 250 40 02

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



-- 
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • <a href="tel:+41%2056%20250%2040%2002" value="+41562504002" target="_blank">+41 56 250 40 02


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Consider date formatting

Maggie Pint
Substantial work is being put into a date standard library and formatting currently. There is a stage 1 proposal to rework the date library here: https://github.com/tc39/proposal-temporal. I have a shim for that proposal started here: https://github.com/maggiepint/temporal-shim. I will probably seek stage two for this proposal in November of January. It is quite large, and the shim and spec text take a long time to write, so it can't be moved quickly.

My plan for formatting is to continue to rely on ECMA 402 as we do today. That team has done a wonderful job in the space, and I'm not entirely sure how i could one-up them at this point.

As far as why that proposal isn't just the Moment.js library - quite a few reasons. I maintain the Moment.js library with a couple other people, and the moment team actually created the new temporal proposal based on the knowledge of where the library falls down, and where other libraries have succeeded. Some points of difference from moment:
Proposal has all immutable data structures
Proposal provides a way to represent a date only, time only, and date time without associated time zone
APIs in several corners have 'safety' features that Moment doesn't have to prevent developer error - for instance the user must specify a time zone on a zoned object

Even after this proposal goes though, I assume there will still be libraries, simply because everyone has different preferences. That said, one should no longer HAVE to bring in a date library for anything as they do today.

On Thu, Sep 21, 2017 at 6:41 AM, Matthew Robb <[hidden email]> wrote:
I just mean to say that it makes more sense as a userland lib outside of the context of browsers.


- Matthew Robb

On Thu, Sep 21, 2017 at 9:35 AM, Michael Kriegel <[hidden email]> wrote:

Actually I used it in node.js today - where using/deploying another lib is less "painful" - agreed. Still I don't think it is browser scope only...


On 21.09.2017 14:59, Matthew Robb wrote:
+1 this sentiment

Raise your hand if you are using Moment.js in projects today?
Raise your hand if you ship the library wholesale?
Raise your hand if you use webpack tok strip out the locale files which add sig. heft to your bundle?

Moment.js should be standardized...

HOWEVER: The language spec is likely the wrong place. This should probably be a browser spec as the biggest motivation is going to be localization which I find obnoxious to include in an often shipped defacto lib.


- Matthew Robb

On Thu, Sep 21, 2017 at 3:17 AM, Michael Kriegel <[hidden email]> wrote:

Quoting my initial posting:

> I know there are libraries for that, but I think it is fundamental enough to put it into the standard instead.

Isn't it legitimate to ask for a defacto-standard to become a real standard...


On 21.09.2017 09:13, Bob Myers wrote:
There are third-party libraries which are so widely-used as to be defacto standards.
Bob

On Thu, Sep 21, 2017 at 12:11 PM, Michael Kriegel <[hidden email]> wrote:
I would like to suggest to take up date formatting into the standard. Either as optional format parameter on Date.prototype.toDateString() or as a separate method Date.prototype.toFormattedDateString(format).

format should be a string in the form as specified in https://tc39.github.io/ecma262/#sec-date-time-string-format

I know there are libraries for that, but I think it is fundamental enough to put it into the standard instead.

I hope this was not already discussed before and I just did not find the thread.

--
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • <a href="tel:+41%2056%20250%2040%2002" value="+41562504002" target="_blank">+41 56 250 40 02


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


-- 
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • <a href="tel:+41%2056%20250%2040%2002" value="+41562504002" target="_blank">+41 56 250 40 02

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



-- 
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • <a href="tel:+41%2056%20250%2040%2002" value="+41562504002" target="_blank">+41 56 250 40 02


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Consider date formatting

kai zhu
going to rant about why existing date builtins are more than adequate, and that over-engineering is the cause of most date-issues (and justify with working vanilla js code).

moment.js is over-engineering and unnecessary.  date manipulation is not that hard using vanilla javascript, if you follow the best-practice of representing it internally throughout your application as a standard utc-iso-string (e.g. "2017-09-21T16:57:06.781Z”).  keeping the date represented as a string-by-default saves you the hassle of doing needless custom-serializations when writing it to json or as a dom-element attribute (not to mention making debugging easier by having human-readable values). it is also sort / comparison-operator friendly as well.

in fact, if you enforce keeping the date represented internally as a string, there are only 3 common-cases that you need to worry about dealing with date serialization/deserialization:
1. date-arithmetic (trivial to do with 3-lines of vanilla javascript code)
2. writing date to the ui and persistent-storage
3. reading date from ui and persistent-storage



```javascript

/*jslint node: true, regexp: true */
'use strict';

function nop() {
/*
 * this function will do nothing
 */
    return;
}

// 1. date-arithmetic
function dateArithmeticAdd(dateIsoString, milliseconds) {
/*
 * this function will return a new dateIsoString with the given (positive or negative) milliseconds added to it
 */
    console.error('dateArithmeticAdd(' + JSON.stringify(dateIsoString) + ',' +
        JSON.stringify(milliseconds) + ')');
    // return serialized dateIsoString
    return new Date(
        // de-serialize dateIsoString and add milliseconds to it
        new Date(dateIsoString).getTime() + milliseconds
    ).toISOString();
}

// 2. writing date to the ui and persistent-storage
function dateWriteToUi(dateIsoString, options) {
/*
 * this function will return the date in a string-format suitable for ui-presentation
 * you can edit this function to suit your application needs
 */
    console.error('dateWriteToUi(' + JSON.stringify(dateIsoString) + ',' +
        JSON.stringify(options) + ')');
    var dateObject;
    // de-serialize dateIsoString
    dateObject = new Date(dateIsoString);
    // present date in local-time instead of utc-time
    if (!options.isUtc) {
        dateObject = new Date(dateObject.getTime() -
            dateObject.getTimezoneOffset() * 60 * 1000);
    }
    dateObject.toISOString().replace((/(\d\d\d\d)-(\d\d)-(\d\d)T(\d\d):(\d\d):(\d\d)/), function (
        match0,
        YYYY,
        MM,
        DD,
        hh,
        mm,
        ss
    ) {
        // jslint-hack
        nop(match0);
        dateObject.YYYY = YYYY;
        dateObject.MM = MM;
        dateObject.DD = DD;
        dateObject.hh = hh;
        dateObject.mm = mm;
        dateObject.ss = ss;
    });
    switch (options.type) {
    case 'china':
        return dateObject.YYYY + '-' +
            dateObject.MM + '-' +
            dateObject.DD + ' ' +
            dateObject.hh + ':' +
            dateObject.mm + ':' +
            dateObject.ss;
    case 'germany':
        return dateObject.DD + '.' +
            dateObject.MM + '.' +
            dateObject.YYYY + ' ' +
            dateObject.hh + ':' +
            dateObject.mm + ':' +
            dateObject.ss;
    case 'usa':
        return dateObject.MM + '/' +
            dateObject.DD + '/' +
            dateObject.YYYY + ' ' +
            dateObject.hh + ':' +
            dateObject.mm + ':' +
            dateObject.ss;
    // case 'foo':
    // ...
    // represent in default locale setting
    default:
        return dateObject.toString();
    }
}

// 3. reading date from ui and persistent-storage
function dateReadFromUi(inputText, options) {
/*
 * this function will parse inputText and return an appropriate dateIsoString
 * you can edit this function to suit your application needs
 */
    console.error('dateReadFromUi(' + JSON.stringify(inputText) + ',' +
        JSON.stringify(options) + ')');
    var dateObject;
    // use default Date parser
    dateObject = new Date(inputText);
    switch (options.type) {
    case 'china':
        inputText.replace((/(\d\d\d\d).(\d\d).(\d\d).(\d\d):(\d\d):(\d\d)/), function (
            match0,
            YYYY,
            MM,
            DD,
            hh,
            mm,
            ss
        ) {
            // jslint-hack
            nop(match0);
            dateObject = new Date(YYYY + '-' + MM + '-' + DD + 'T' + hh + ':' + mm + ':' + ss);
        });
        break;
    case 'germany':
        inputText.replace((/(\d\d).(\d\d).(\d\d\d\d).(\d\d):(\d\d):(\d\d)/), function (
            match0,
            DD,
            MM,
            YYYY,
            hh,
            mm,
            ss
        ) {
            // jslint-hack
            nop(match0);
            dateObject = new Date(YYYY + '-' + MM + '-' + DD + 'T' + hh + ':' + mm + ':' + ss);
        });
        break;
    case 'usa':
        inputText.replace((/(\d\d).(\d\d).(\d\d\d\d).(\d\d):(\d\d):(\d\d)/), function (
            match0,
            MM,
            DD,
            YYYY,
            hh,
            mm,
            ss
        ) {
            // jslint-hack
            nop(match0);
            dateObject = new Date(YYYY + '-' + MM + '-' + DD + 'T' + hh + ':' + mm + ':' + ss);
        });
        break;
    // case 'foo':
    // ...
    }
    // inputText was in utc-time
    if (options.isUtc) {
        dateObject = new Date(dateObject.getTime() -
            dateObject.getTimezoneOffset() * 60 * 1000);
    }
    return dateObject.toISOString();
}

// 1. date-arithmetic
console.log('\n1. date-arithmetic');
console.log(dateArithmeticAdd('2000-01-30T00:00:00Z', 24 * 60 * 60 * 1000));
console.log(dateArithmeticAdd('2000-01-30T00:00:00Z', -24 * 60 * 60 * 1000));

// 2. writing date to the ui and persistent-storage
console.log('\n2. writing date to the ui and persistent-storage');
console.log(dateWriteToUi('2000-01-30T00:00:00Z', { type: 'china' }));
console.log(dateWriteToUi('2000-01-30T00:00:00Z', { type: 'china', isUtc: true }));
console.log(dateWriteToUi('2000-01-30T00:00:00Z', { type: 'germany' }));
console.log(dateWriteToUi('2000-01-30T00:00:00Z', { type: 'germany', isUtc: true }));
console.log(dateWriteToUi('2000-01-30T00:00:00Z', { type: 'usa' }));
console.log(dateWriteToUi('2000-01-30T00:00:00Z', { type: 'usa', isUtc: true }));

// 3. reading date from ui and persistent-storage
console.log('\n3. reading date from ui and persistent-storage');
console.log(dateReadFromUi('2000-01-30 00:00:00', { type: 'china' }));
console.log(dateReadFromUi('2000-01-30 00:00:00', { type: 'china', isUtc: true }));
console.log(dateReadFromUi('30.01.2000 00:00:00', { type: 'germany' }));
console.log(dateReadFromUi('30.01.2000 00:00:00', { type: 'germany', isUtc: true }));
console.log(dateReadFromUi('01/30/2000 00:00:00', { type: 'usa' }));
console.log(dateReadFromUi('01/30/2000 00:00:00', { type: 'usa', isUtc: true }));

```


On Sep 21, 2017, at 9:04 PM, Maggie Pint <[hidden email]> wrote:

Substantial work is being put into a date standard library and formatting currently. There is a stage 1 proposal to rework the date library here: https://github.com/tc39/proposal-temporal. I have a shim for that proposal started here: https://github.com/maggiepint/temporal-shim. I will probably seek stage two for this proposal in November of January. It is quite large, and the shim and spec text take a long time to write, so it can't be moved quickly.

My plan for formatting is to continue to rely on ECMA 402 as we do today. That team has done a wonderful job in the space, and I'm not entirely sure how i could one-up them at this point.

As far as why that proposal isn't just the Moment.js library - quite a few reasons. I maintain the Moment.js library with a couple other people, and the moment team actually created the new temporal proposal based on the knowledge of where the library falls down, and where other libraries have succeeded. Some points of difference from moment:
Proposal has all immutable data structures
Proposal provides a way to represent a date only, time only, and date time without associated time zone
APIs in several corners have 'safety' features that Moment doesn't have to prevent developer error - for instance the user must specify a time zone on a zoned object

Even after this proposal goes though, I assume there will still be libraries, simply because everyone has different preferences. That said, one should no longer HAVE to bring in a date library for anything as they do today.

On Thu, Sep 21, 2017 at 6:41 AM, Matthew Robb <[hidden email]> wrote:
I just mean to say that it makes more sense as a userland lib outside of the context of browsers.


- Matthew Robb

On Thu, Sep 21, 2017 at 9:35 AM, Michael Kriegel <[hidden email]> wrote:

Actually I used it in node.js today - where using/deploying another lib is less "painful" - agreed. Still I don't think it is browser scope only...


On 21.09.2017 14:59, Matthew Robb wrote:
+1 this sentiment

Raise your hand if you are using Moment.js in projects today?
Raise your hand if you ship the library wholesale?
Raise your hand if you use webpack tok strip out the locale files which add sig. heft to your bundle?

Moment.js should be standardized...

HOWEVER: The language spec is likely the wrong place. This should probably be a browser spec as the biggest motivation is going to be localization which I find obnoxious to include in an often shipped defacto lib.


- Matthew Robb

On Thu, Sep 21, 2017 at 3:17 AM, Michael Kriegel <[hidden email]> wrote:

Quoting my initial posting:

> I know there are libraries for that, but I think it is fundamental enough to put it into the standard instead.

Isn't it legitimate to ask for a defacto-standard to become a real standard...


On 21.09.2017 09:13, Bob Myers wrote:
There are third-party libraries which are so widely-used as to be defacto standards.
Bob

On Thu, Sep 21, 2017 at 12:11 PM, Michael Kriegel <[hidden email]> wrote:
I would like to suggest to take up date formatting into the standard. Either as optional format parameter on Date.prototype.toDateString() or as a separate method Date.prototype.toFormattedDateString(format).

format should be a string in the form as specified in https://tc39.github.io/ecma262/#sec-date-time-string-format

I know there are libraries for that, but I think it is fundamental enough to put it into the standard instead.

I hope this was not already discussed before and I just did not find the thread.

--
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • <a href="tel:+41%2056%20250%2040%2002" value="+41562504002" target="_blank" class="">+41 56 250 40 02


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


-- 
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • <a href="tel:+41%2056%20250%2040%2002" value="+41562504002" target="_blank" class="">+41 56 250 40 02

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



-- 
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • <a href="tel:+41%2056%20250%2040%2002" value="+41562504002" target="_blank" class="">+41 56 250 40 02


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Consider date formatting

Darien Valentine
In reply to this post by Michael Kriegel
I think there is a pretty good case to be made for native support for pattern-based formatting as the OP described. I believe it has prior art in other languages and, while the highly configurable, internationalized formatting provided by `Intl.DateTimeFormat.prototype.format` is very valuable, pattern-based formatting serves different purposes.

@ Maggie I’m very excited to see ES getting distinct, hack-free types for representing the different kinds of date/date time values that we often awkwardly conflate with the generic datetime Date. The immutability is refreshing — I cannot think of a time I ever thought "gee, I’m glad date objects are mutable".

@ kai zhu, I appreciate the perspective you try to bring to things on these forums, but I don’t think that your campaign for simplicity is well-served by arguing that people should roll their own date manipulation utilities. :) In many cases, it’s true that one needs nothing more than Date, and it’s also been my experience that sometimes when people think "but timezones!" they are creating, not solving, problems. However, cases that do demand more nuance aren’t uncommon, and when you wrote that date arithmetic is "trivial to do with 3-lines of vanilla javascript code", ten thousand dead developers briefly reanimated in their graves and hissed demonic curses.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Consider date formatting

Caridy Patino
Intl.DateTimeFormat is a low level API that is very powerful, and we will continue evolving it. Intl.DateTimeFormat.prototype.formatToParts is just one more thing that we have added recently (stage 4). Patterns, and Skeletons (which are not the same) have been a topic of discussion many times, e.g.: https://github.com/tc39/ecma402/issues/108, and I hope we can continue those discussions.

Unfortunately, pattern seems to be a foot gun. It is only really useful to folks with a very specific requirement per locale, which means they need to define the pattern that they want per locale, and that sort of conflicts with the philosophy behind DateTimeFormat, and not many people realize that.

OTOH, skeleton is pretty much equivalent to what we have today via options, whether it has better ergonomics is debatable IMO. Additionally, Mozilla folks have been proposing some reforms to introduce a more simple form of skeleton that matches the OS configuration.

Bottom line, we are progressing in various fronts (date manipulation and formatting), and these are very exciting times for anyone who is interested in these topics, just come and help us in https://github.com/tc39/ecma402/ :)

./caridy

On Sep 21, 2017, at 11:58 PM, Darien Valentine <[hidden email]> wrote:

I think there is a pretty good case to be made for native support for pattern-based formatting as the OP described. I believe it has prior art in other languages and, while the highly configurable, internationalized formatting provided by `Intl.DateTimeFormat.prototype.format` is very valuable, pattern-based formatting serves different purposes.

@ Maggie I’m very excited to see ES getting distinct, hack-free types for representing the different kinds of date/date time values that we often awkwardly conflate with the generic datetime Date. The immutability is refreshing — I cannot think of a time I ever thought "gee, I’m glad date objects are mutable".

@ kai zhu, I appreciate the perspective you try to bring to things on these forums, but I don’t think that your campaign for simplicity is well-served by arguing that people should roll their own date manipulation utilities. :) In many cases, it’s true that one needs nothing more than Date, and it’s also been my experience that sometimes when people think "but timezones!" they are creating, not solving, problems. However, cases that do demand more nuance aren’t uncommon, and when you wrote that date arithmetic is "trivial to do with 3-lines of vanilla javascript code", ten thousand dead developers briefly reanimated in their graves and hissed demonic curses.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Consider date formatting

Barret Furton
In reply to this post by kai zhu
@kai zhu Your implementation isn’t ISO 8601 compliant. Separators are optional, dates don’t need to include any time information, and there are additional formats for week number and headless dates that your implementation doesn’t support. Furthermore, at least one of your RegExp matchers has bugs in its implementation (matching all characters instead of a literal “.”). Moment.js is one of the most well-tested libraries in the JS community, which is part of why it sees such widespread adoption. And it’s not for lack of trying, either. I’ve worked with devs who are hesitant to add another lib to their stack and attempt date manipulation themselves, working out all the bugs, then finally giving up when they realize that their implementation breaks 3 different ways in Firefox, Safari, and IE.

On Thu, Sep 21, 2017 at 4:23 PM kai zhu <[hidden email]> wrote:
going to rant about why existing date builtins are more than adequate, and that over-engineering is the cause of most date-issues (and justify with working vanilla js code).

moment.js is over-engineering and unnecessary.  date manipulation is not that hard using vanilla javascript, if you follow the best-practice of representing it internally throughout your application as a standard utc-iso-string (e.g. "2017-09-21T16:57:06.781Z”).  keeping the date represented as a string-by-default saves you the hassle of doing needless custom-serializations when writing it to json or as a dom-element attribute (not to mention making debugging easier by having human-readable values). it is also sort / comparison-operator friendly as well.

in fact, if you enforce keeping the date represented internally as a string, there are only 3 common-cases that you need to worry about dealing with date serialization/deserialization:
1. date-arithmetic (trivial to do with 3-lines of vanilla javascript code)
2. writing date to the ui and persistent-storage
3. reading date from ui and persistent-storage



```javascript

/*jslint node: true, regexp: true */
'use strict';

function nop() {
/*
 * this function will do nothing
 */
    return;
}

// 1. date-arithmetic
function dateArithmeticAdd(dateIsoString, milliseconds) {
/*
 * this function will return a new dateIsoString with the given (positive or negative) milliseconds added to it
 */
    console.error('dateArithmeticAdd(' + JSON.stringify(dateIsoString) + ',' +
        JSON.stringify(milliseconds) + ')');
    // return serialized dateIsoString
    return new Date(
        // de-serialize dateIsoString and add milliseconds to it
        new Date(dateIsoString).getTime() + milliseconds
    ).toISOString();
}

// 2. writing date to the ui and persistent-storage
function dateWriteToUi(dateIsoString, options) {
/*
 * this function will return the date in a string-format suitable for ui-presentation
 * you can edit this function to suit your application needs
 */
    console.error('dateWriteToUi(' + JSON.stringify(dateIsoString) + ',' +
        JSON.stringify(options) + ')');
    var dateObject;
    // de-serialize dateIsoString
    dateObject = new Date(dateIsoString);
    // present date in local-time instead of utc-time
    if (!options.isUtc) {
        dateObject = new Date(dateObject.getTime() -
            dateObject.getTimezoneOffset() * 60 * 1000);
    }
    dateObject.toISOString().replace((/(\d\d\d\d)-(\d\d)-(\d\d)T(\d\d):(\d\d):(\d\d)/), function (
        match0,
        YYYY,
        MM,
        DD,
        hh,
        mm,
        ss
    ) {
        // jslint-hack
        nop(match0);
        dateObject.YYYY = YYYY;
        dateObject.MM = MM;
        dateObject.DD = DD;
        dateObject.hh = hh;
        dateObject.mm = mm;
        dateObject.ss = ss;
    });
    switch (options.type) {
    case 'china':
        return dateObject.YYYY + '-' +
            dateObject.MM + '-' +
            dateObject.DD + ' ' +
            dateObject.hh + ':' +
            dateObject.mm + ':' +
            dateObject.ss;
    case 'germany':
        return dateObject.DD + '.' +
            dateObject.MM + '.' +
            dateObject.YYYY + ' ' +
            dateObject.hh + ':' +
            dateObject.mm + ':' +
            dateObject.ss;
    case 'usa':
        return dateObject.MM + '/' +
            dateObject.DD + '/' +
            dateObject.YYYY + ' ' +
            dateObject.hh + ':' +
            dateObject.mm + ':' +
            dateObject.ss;
    // case 'foo':
    // ...
    // represent in default locale setting
    default:
        return dateObject.toString();
    }
}

// 3. reading date from ui and persistent-storage
function dateReadFromUi(inputText, options) {
/*
 * this function will parse inputText and return an appropriate dateIsoString
 * you can edit this function to suit your application needs
 */
    console.error('dateReadFromUi(' + JSON.stringify(inputText) + ',' +
        JSON.stringify(options) + ')');
    var dateObject;
    // use default Date parser
    dateObject = new Date(inputText);
    switch (options.type) {
    case 'china':
        inputText.replace((/(\d\d\d\d).(\d\d).(\d\d).(\d\d):(\d\d):(\d\d)/), function (
            match0,
            YYYY,
            MM,
            DD,
            hh,
            mm,
            ss
        ) {
            // jslint-hack
            nop(match0);
            dateObject = new Date(YYYY + '-' + MM + '-' + DD + 'T' + hh + ':' + mm + ':' + ss);
        });
        break;
    case 'germany':
        inputText.replace((/(\d\d).(\d\d).(\d\d\d\d).(\d\d):(\d\d):(\d\d)/), function (
            match0,
            DD,
            MM,
            YYYY,
            hh,
            mm,
            ss
        ) {
            // jslint-hack
            nop(match0);
            dateObject = new Date(YYYY + '-' + MM + '-' + DD + 'T' + hh + ':' + mm + ':' + ss);
        });
        break;
    case 'usa':
        inputText.replace((/(\d\d).(\d\d).(\d\d\d\d).(\d\d):(\d\d):(\d\d)/), function (
            match0,
            MM,
            DD,
            YYYY,
            hh,
            mm,
            ss
        ) {
            // jslint-hack
            nop(match0);
            dateObject = new Date(YYYY + '-' + MM + '-' + DD + 'T' + hh + ':' + mm + ':' + ss);
        });
        break;
    // case 'foo':
    // ...
    }
    // inputText was in utc-time
    if (options.isUtc) {
        dateObject = new Date(dateObject.getTime() -
            dateObject.getTimezoneOffset() * 60 * 1000);
    }
    return dateObject.toISOString();
}

// 1. date-arithmetic
console.log('\n1. date-arithmetic');
console.log(dateArithmeticAdd('2000-01-30T00:00:00Z', 24 * 60 * 60 * 1000));
console.log(dateArithmeticAdd('2000-01-30T00:00:00Z', -24 * 60 * 60 * 1000));

// 2. writing date to the ui and persistent-storage
console.log('\n2. writing date to the ui and persistent-storage');
console.log(dateWriteToUi('2000-01-30T00:00:00Z', { type: 'china' }));
console.log(dateWriteToUi('2000-01-30T00:00:00Z', { type: 'china', isUtc: true }));
console.log(dateWriteToUi('2000-01-30T00:00:00Z', { type: 'germany' }));
console.log(dateWriteToUi('2000-01-30T00:00:00Z', { type: 'germany', isUtc: true }));
console.log(dateWriteToUi('2000-01-30T00:00:00Z', { type: 'usa' }));
console.log(dateWriteToUi('2000-01-30T00:00:00Z', { type: 'usa', isUtc: true }));

// 3. reading date from ui and persistent-storage
console.log('\n3. reading date from ui and persistent-storage');
console.log(dateReadFromUi('2000-01-30 00:00:00', { type: 'china' }));
console.log(dateReadFromUi('2000-01-30 00:00:00', { type: 'china', isUtc: true }));
console.log(dateReadFromUi('30.01.2000 00:00:00', { type: 'germany' }));
console.log(dateReadFromUi('30.01.2000 00:00:00', { type: 'germany', isUtc: true }));
console.log(dateReadFromUi('01/30/2000 00:00:00', { type: 'usa' }));
console.log(dateReadFromUi('01/30/2000 00:00:00', { type: 'usa', isUtc: true }));

```


On Sep 21, 2017, at 9:04 PM, Maggie Pint <[hidden email]> wrote:

Substantial work is being put into a date standard library and formatting currently. There is a stage 1 proposal to rework the date library here: https://github.com/tc39/proposal-temporal. I have a shim for that proposal started here: https://github.com/maggiepint/temporal-shim. I will probably seek stage two for this proposal in November of January. It is quite large, and the shim and spec text take a long time to write, so it can't be moved quickly.

My plan for formatting is to continue to rely on ECMA 402 as we do today. That team has done a wonderful job in the space, and I'm not entirely sure how i could one-up them at this point.

As far as why that proposal isn't just the Moment.js library - quite a few reasons. I maintain the Moment.js library with a couple other people, and the moment team actually created the new temporal proposal based on the knowledge of where the library falls down, and where other libraries have succeeded. Some points of difference from moment:
Proposal has all immutable data structures
Proposal provides a way to represent a date only, time only, and date time without associated time zone
APIs in several corners have 'safety' features that Moment doesn't have to prevent developer error - for instance the user must specify a time zone on a zoned object

Even after this proposal goes though, I assume there will still be libraries, simply because everyone has different preferences. That said, one should no longer HAVE to bring in a date library for anything as they do today.

On Thu, Sep 21, 2017 at 6:41 AM, Matthew Robb <[hidden email]> wrote:
I just mean to say that it makes more sense as a userland lib outside of the context of browsers.


- Matthew Robb

On Thu, Sep 21, 2017 at 9:35 AM, Michael Kriegel <[hidden email]> wrote:

Actually I used it in node.js today - where using/deploying another lib is less "painful" - agreed. Still I don't think it is browser scope only...


On 21.09.2017 14:59, Matthew Robb wrote:
+1 this sentiment

Raise your hand if you are using Moment.js in projects today?
Raise your hand if you ship the library wholesale?
Raise your hand if you use webpack tok strip out the locale files which add sig. heft to your bundle?

Moment.js should be standardized...

HOWEVER: The language spec is likely the wrong place. This should probably be a browser spec as the biggest motivation is going to be localization which I find obnoxious to include in an often shipped defacto lib.


- Matthew Robb

On Thu, Sep 21, 2017 at 3:17 AM, Michael Kriegel <[hidden email]> wrote:

Quoting my initial posting:

> I know there are libraries for that, but I think it is fundamental enough to put it into the standard instead.

Isn't it legitimate to ask for a defacto-standard to become a real standard...


On 21.09.2017 09:13, Bob Myers wrote:
There are third-party libraries which are so widely-used as to be defacto standards.
Bob

On Thu, Sep 21, 2017 at 12:11 PM, Michael Kriegel <[hidden email]> wrote:
I would like to suggest to take up date formatting into the standard. Either as optional format parameter on Date.prototype.toDateString() or as a separate method Date.prototype.toFormattedDateString(format).

format should be a string in the form as specified in https://tc39.github.io/ecma262/#sec-date-time-string-format

I know there are libraries for that, but I think it is fundamental enough to put it into the standard instead.

I hope this was not already discussed before and I just did not find the thread.

--
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • <a href="tel:+41%2056%20250%2040%2002" value="+41562504002" target="_blank">+41 56 250 40 02


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


-- 
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • <a href="tel:+41%2056%20250%2040%2002" value="+41562504002" target="_blank">+41 56 250 40 02

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



-- 
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • <a href="tel:+41%2056%20250%2040%2002" value="+41562504002" target="_blank">+41 56 250 40 02


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

PastedGraphic-8.png (1018K) Download Attachment