profile
viewpoint

heycam/webidl 183

Web IDL

Ms2ger/dom.js 4

Self-hosted JavaScript implementation of a WebIDL-compliant HTML5 DOM.

jdm/servo 2

The Servo Browser Engine

jgraham/css-test-built 2

Built version of the CSSWG tests, ready to run

jgraham/servo 0

The Servo Browser Engine

littledan/ecma402 0

Status, process, and documents for ECMA 402

littledan/proposal-dynamic-import 0

import() proposal for JavaScript

push eventtc39/proposal-temporal

Deployment Bot (from Travis CI)

commit sha e439064890560fa7937a0dd9d2c10ea15d13b832

Deploy tc39/proposal-temporal to github.com/tc39/proposal-temporal.git:gh-pages

view details

push time in 9 hours

push eventtc39/proposal-temporal

Deployment Bot (from Travis CI)

commit sha 0f911f633a55a3872739e995085027d041d1c04e

Deploy tc39/proposal-temporal to github.com/tc39/proposal-temporal.git:gh-pages

view details

push time in 9 hours

issue commenttc39/proposal-temporal

Consistent pattern for additive conversion method parameters

I'm trying to figure out what this would involve, exactly.

  • Date/Time toDateTime are okay AFAICT
  • MonthDay toDateInYear
    • Drop the options argument?
    • Add string argument? No clue what kind of format, though.
  • YearMonth toDateOnDay
    • Add support for { day }? Seems pretty pointless
  • Instant toDateTime: might be removed in #1026
  • toLocalDateTime: doesn't exist yet

Anything I'm missing?

justingrant

comment created time in 13 hours

push eventtc39/proposal-temporal

Deployment Bot (from Travis CI)

commit sha 88fb475fbc30db4efd531a4818a04ab922494908

Deploy tc39/proposal-temporal to github.com/tc39/proposal-temporal.git:gh-pages

view details

push time in 19 hours

push eventtc39/proposal-temporal

Ujjwal Sharma

commit sha 89aaa59834731e0151670e29b7dedd5e39a44858

spec: update Intl to use ISO prefixed slot names Fixes: https://github.com/tc39/proposal-temporal/issues/1022

view details

push time in 19 hours

PR merged tc39/proposal-temporal

spec: update Intl to use ISO prefixed slot names

Fixes: https://github.com/tc39/proposal-temporal/issues/1022

/cc @Ms2ger

+4 -4

1 comment

1 changed file

ryzokuken

pr closed time in 19 hours

issue closedtc39/proposal-temporal

Intl section needs to use ISO-prefixed internal slots

date.[[ISOYear]] rather than date.[[Year]], etc.

closed time in 19 hours

Ms2ger
PullRequestReviewEvent

push eventtc39/proposal-temporal

Deployment Bot (from Travis CI)

commit sha 934624537ab53d7dbb27f441e5605b5eb029bec0

Deploy tc39/proposal-temporal to github.com/tc39/proposal-temporal.git:gh-pages

view details

push time in 20 hours

push eventtc39/proposal-temporal

Justin Grant

commit sha fe9e5c7bce5d7108b67a3dd35ec43432b3b216c2

Misc docs and JSDoc updates * Clarify roundingMode docs (fixes #1028) * Consistent order for roundingMode options * Clarify that `relativeTo` can also accept a Date * Added JSDoc content to index.d.ts to mirror the docs changes above. * Added JSDoc content for new xxxISO methods of Temporal.now * Added JSDoc content for duration rounding options * Renamed `offsetString` to `offset` in ZonedDateTime docs * Ran prettier for the first time on duration.md and yearmonth.md, so many whitespace changes, code semicolons, etc. I also added prettier-ignore comments where needed to retain code formatting.

view details

push time in 20 hours

PR merged tc39/proposal-temporal

Reviewers
Misc documentation and JSDoc updates
  • Clarify roundingMode docs (fixes #1028)
  • Consistent order for roundingMode options
  • Clarify that relativeTo can also accept a Date
  • Added JSDoc content to index.d.ts to mirror the docs changes above.
  • Added JSDoc content for new xxxISO methods of Temporal.now
  • Added JSDoc content for duration rounding options
  • Renamed offsetString to offset in ZonedDateTime docs
  • Ran prettier for the first time on duration.md and yearmonth.md, so many whitespace changes, code semicolons, etc. I also added prettier-ignore comments where needed to retain code formatting.
+308 -139

1 comment

8 changed files

justingrant

pr closed time in 20 hours

issue closedtc39/proposal-temporal

Docs should clarify that `nearest` rounding mode rounds away from zero, not towards positive infinity

I just wasted an hour trying to figure out why my tests were breaking until I realized that ceil means "round up" not "round away from zero". Doh! But that fun experience led me to the Duration docs:

  • ceil: Always round up, towards positive infinity.
  • floor: Always round down, towards negative infinity.
  • trunc: Always round towards zero, chopping off the part after the decimal point.
  • nearest: Round to the nearest of the values allowed by roundingIncrement and smallestUnit. When there is a tie, round up, like ceil.

The documentation for nearest ties is wrong for negative durations. When there's a tie when rounding negative durations, the polyfill is implemented to round away from zero, not towards positive infinity like ceil. From #827:

  • 5.4.4 'nearest' - round to nearest integer, with 0.5 rounded away from zero.

Example:

Temporal.Duration.from({hours: 2, minutes: 30}).round({ smallestUnit: 'hours'})
// => PT3H
Temporal.Duration.from({hours: -2, minutes: -30}).round({ smallestUnit: 'hours'})
// => -PT3H

I believe that this is the correct behavior for nearest, and that we should change the docs. I'd PR this myself but I'm in the middle of trying to wrap up ZonedDateTime, so filing an issue instead.

closed time in 20 hours

justingrant
PullRequestReviewEvent

push eventtc39/proposal-temporal

Deployment Bot (from Travis CI)

commit sha d91a7c101c1566c9c8ef260d3d2fbdabde0a0d23

Deploy tc39/proposal-temporal to github.com/tc39/proposal-temporal.git:gh-pages

view details

push time in 20 hours

push eventtc39/proposal-temporal

Ujjwal Sharma

commit sha 19c6e7d977c41bda86e17767eac02e2679ad2d80

spec: PartitionDateTimePattern rename date to x

view details

Ujjwal Sharma

commit sha c2862697868dbb3086bb4dfb187c8705a4a79f04

spec: PartitionDateTimePattern convert RangeErrors to oneliners

view details

Ujjwal Sharma

commit sha 51c3159debc353f4aed8674b9dfa5bb539312ec6

spec: fix CalendarToString calls in PartitionDateTimePattern

view details

push time in 20 hours

PR merged tc39/proposal-temporal

spec: PartitionDateTimePattern improvements

/cc @sffc @ptomato @Ms2ger these should basically be enough to make PartitionDateTimePattern work as expected with all types. One thing I was not sure about was if one of YM and MD doesn't have a calendar (perhaps MD?), but it is impossible to tell from the docs.

+27 -32

1 comment

1 changed file

ryzokuken

pr closed time in 20 hours

PullRequestReviewEvent

push eventtc39/proposal-temporal

Deployment Bot (from Travis CI)

commit sha 83ee35aa9cd14e3149c00cf94cd7d9e106950ec2

Deploy tc39/proposal-temporal to github.com/tc39/proposal-temporal.git:gh-pages

view details

push time in 21 hours

push eventtc39/proposal-temporal

Deployment Bot (from Travis CI)

commit sha 6ac0ee005aead46d6563f287de3096e85a21549b

Deploy tc39/proposal-temporal to github.com/tc39/proposal-temporal.git:gh-pages

view details

push time in 2 days

push eventtc39/proposal-temporal

Ujjwal Sharma

commit sha cef78558aad6c7e9aba47fbd8e946f4c1545a6f7

spec: fix instant handling in PartitionDateTimePattern Handle Instants properly in PartitionDateTimePattern (convert to DateTime and move forward from there). Fixes: https://github.com/tc39/proposal-temporal/issues/456

view details

push time in 2 days

PR merged tc39/proposal-temporal

spec: fix instant handling in PartitionDateTimePattern awaiting-author

Handle Instants properly in PartitionDateTimePattern (convert to DateTime and move forward from there).

Fixes: https://github.com/tc39/proposal-temporal/issues/456

/cc @Ms2ger @sffc

There's a bunch of bigger issues in PartitionDateTimePattern but I suppose we can solve them one at a time?

+4 -0

1 comment

1 changed file

ryzokuken

pr closed time in 2 days

issue closedtc39/proposal-temporal

Intl.DateTimeFormat with Absolute

Currently PartitionDateTimePattern treats Absolute and DateTime the same, using [[Year]] (etc.) internal slots, which don't exist in Absolute instances. Not sure what's the expected behaviour is.

closed time in 2 days

Ms2ger
PullRequestReviewEvent

Pull request review commenttc39/proposal-temporal

spec: fix instant handling in PartitionDateTimePattern

 <h1>PartitionDateTimePattern ( _dateTimeFormat_, <del>_x_</del><ins>_date_</ins>           1. <ins>If _date_ has an [[InitializedTemporalTime]] internal slot, then</ins>             1. <ins>Let _pattern_ be _dateTimeFormat_.[[TemporalTimePattern]].</ins>             1. <ins>Let _tm_ be { [[hour]]: _date_.[[Hour]], [[minute]]: _date_.[[Minute]], [[second]]: _date_.[[Second]] }.</ins>-          1. <ins>If _date_ has an [[InitializedTemporalDateTime]] or an [[InitializedTemporalInstant]] internal slot, then</ins>+          1. <ins>If _date_ has an [[InitializedTemporalInstant]] internal slot, then</ins>+            1. <ins>Let _timeZone_ be ? TimeZoneFrom(_dateTimeFormat_.[[TimeZone]]).</ins>+            1. <ins>Let _calendar_ be ? CalendarFrom(_dateTimeFormat_.[[Calendar]]).</ins>+            1. <ins>Set _date_ to ? GetTemporalDateTimeFor(_timeZone_, _instant_, _calendar_).</ins>+          1. <ins>If _date_ has an [[InitializedTemporalDateTime]] internal slot, then</ins>

Oh, this is supposed to fall through? I really don't like that; can we avoid it?

ryzokuken

comment created time in 2 days

Pull request review commenttc39/proposal-temporal

spec: fix instant handling in PartitionDateTimePattern

 <h1>PartitionDateTimePattern ( _dateTimeFormat_, <del>_x_</del><ins>_date_</ins>           1. <ins>If _date_ has an [[InitializedTemporalTime]] internal slot, then</ins>             1. <ins>Let _pattern_ be _dateTimeFormat_.[[TemporalTimePattern]].</ins>             1. <ins>Let _tm_ be { [[hour]]: _date_.[[Hour]], [[minute]]: _date_.[[Minute]], [[second]]: _date_.[[Second]] }.</ins>-          1. <ins>If _date_ has an [[InitializedTemporalDateTime]] or an [[InitializedTemporalInstant]] internal slot, then</ins>+          1. <ins>If _date_ has an [[InitializedTemporalInstant]] internal slot, then</ins>+            1. <ins>Let _timeZone_ be ? TimeZoneFrom(_dateTimeFormat_.[[TimeZone]]).</ins>+            1. <ins>Let _calendar_ be ? CalendarFrom(_dateTimeFormat_.[[Calendar]]).</ins>+            1. <ins>Set _date_ to ? GetTemporalDateTimeFor(_timeZone_, _instant_, _calendar_).</ins>+          1. <ins>If _date_ has an [[InitializedTemporalDateTime]] internal slot, then</ins>             1. <ins>Let _calendar_ be ? CalendarToString(_x_).</ins>

Followup: all of these are wrong. Should be CalendarToString(_date_.[[Calendar]]).

ryzokuken

comment created time in 2 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commenttc39/proposal-temporal

Calendar.fields method

 <h1>DifferenceDate ( _y1_, _m1_, _d1_, _y2_, _m2_, _d2_, _largestUnit_ )</h1>       </emu-alg>     </emu-clause> -    <emu-clause id="sec-temporal-totemporaldaterecord" aoid="ToTemporalDateRecord">-      <h1>ToTemporalDateRecord ( _temporalDateLike_ )</h1>+    <emu-clause id="sec-temporal-totemporaldatefields" aoid="ToTemporalDateFields">+      <h1>ToTemporalDateFields ( _temporalDateLike_, _calendar_ )</h1>       <emu-alg>         1. Assert: Type(_temporalDateLike_) is Object.-        1. If _temporalDateLike_ has an [[InitializedTemporalDate]] internal slot, then-          1. Return the Record {-              [[Year]]: _temporalDateLike_.[[Year]],-              [[Month]]: _temporalDateLike_.[[Month]],-              [[Day]]: _temporalDateLike_.[[Day]],-            }.-        1. Let _result_ be a new Record with all the internal slots given in the Internal Slot column in <emu-xref href="#table-temporal-temporaldatelike-properties"></emu-xref>.-        1. For each row of <emu-xref href="#table-temporal-temporaldatelike-properties"></emu-xref>, except the header row, in table order, do-          1. Let _property_ be the Property value of the current row.+        1. Let _fieldsMethod_ be ? Get(_calendar_, *fields*).+        1. Let _fields_ be ? CreateArrayFromList(« *"day"*, *"era"*, *"month"*, *"year"* »).+        1. Set _fields_ to ? Call(_fieldsMethod_, _calendar_, « _fields_ »).+        1. Let _result_ be ? OrdinaryObjectCreate(%Object.prototype%).+        1. For each value _property_ of _fields_, do           1. Let _value_ be ? Get(_temporalDateLike_, _property_).-          1. If _value_ is *undefined*, then+          1. If _property_ is one of *"day"*, *"month"*, or *"year"*, and _value_ is *undefined*, then             1. Throw a *TypeError* exception.-          1. Let _value_ be ? ToInteger(_value_).-          1. Set _result_'s internal slot whose name is the Internal Slot value of the current row to _value_.+          1. If _property_ is not *"era"*, then+            1. Let _value_ be ? ToInteger(_value_).

This makes no sense to me: this would convert any custom property to an integer?

ptomato

comment created time in 2 days

Pull request review commenttc39/proposal-temporal

Calendar.fields method

 export const ES = ObjectAssign({}, ES2020, {       throw new RangeError(`${property} must be between ${minimum} and ${maximum}, not ${value}`);     }     return MathFloor(value);+  },+  // Overridden because the es-abstract version unconditionally uses util.inspect+  Get: (O, P) => {+    if (Type(O) !== 'Object') {+      throw new TypeError('Assertion failed: Type(O) is not Object');+    }+    if (!ES.IsPropertyKey(P)) {+      throw new TypeError(`Assertion failed: IsPropertyKey(P) is not true, got ${P}`);+    }+    return O[P];+  },+  LengthOfArrayLike: (obj) => {+    if (Type(obj) !== 'Object') {+      throw new TypeError('Assertion failed: `obj` must be an Object');+    }+    return ES.ToLength(ES.Get(obj, 'length'));+  },+  CreateListFromArrayLike: (+    obj,+    elementTypes = ['Undefined', 'Null', 'Boolean', 'String', 'Symbol', 'Number', 'Object']

I wouldn't mind specializing to only String for the polyfill.

ptomato

comment created time in 2 days

Pull request review commenttc39/proposal-temporal

Calendar.fields method

 export const ES = ObjectAssign({}, ES2020, {       throw new RangeError(`${property} must be between ${minimum} and ${maximum}, not ${value}`);     }     return MathFloor(value);+  },+  // Overridden because the es-abstract version unconditionally uses util.inspect+  Get: (O, P) => {+    if (Type(O) !== 'Object') {

More consistent to use ES.Type()?

ptomato

comment created time in 2 days

Pull request review commenttc39/proposal-temporal

Calendar.fields method

 export class Date {     if (!ES.IsTemporalDate(this)) throw new TypeError('invalid receiver');     const YearMonth = GetIntrinsic('%Temporal.YearMonth%');     const calendar = GetSlot(this, CALENDAR);-    const fields = ES.ToTemporalDateRecord(this);+    const fields = ES.ToTemporalDateFields(this, calendar);     return calendar.yearMonthFromFields(fields, {}, YearMonth);   }   toMonthDay() {     if (!ES.IsTemporalDate(this)) throw new TypeError('invalid receiver');     const MonthDay = GetIntrinsic('%Temporal.MonthDay%');     const calendar = GetSlot(this, CALENDAR);-    const fields = ES.ToTemporalDateRecord(this);+    const fields = ES.ToTemporalDateFields(this, calendar);     return calendar.monthDayFromFields(fields, {}, MonthDay);   }   getFields() {-    const fields = ES.ToTemporalDateRecord(this);-    if (!fields) throw new TypeError('invalid receiver');-    fields.calendar = GetSlot(this, CALENDAR);+    if (!ES.IsTemporalDate(this)) throw new TypeError('invalid receiver');+    const calendar = GetSlot(this, CALENDAR);+    const fields = ES.ToTemporalDateFields(this, calendar);+    fields.calendar = calendar;

What if fields() returns "calendar" as one of the fields?

ptomato

comment created time in 2 days

Pull request review commenttc39/proposal-temporal

Calendar.fields method

 export class Date {       calendar = GetSlot(this, CALENDAR);       source = this;     }-    const props = ES.ToPartialRecord(temporalDateLike, ['day', 'era', 'month', 'year']);+    const fieldNames = calendar.fields(['day', 'era', 'month', 'year']);+    const props = ES.ToPartialRecord(temporalDateLike, fieldNames);     if (!props) {       throw new TypeError('invalid date-like');     }-    const fields = ES.ToTemporalDateRecord(source);+    const fields = ES.ToTemporalDateFields(source, calendar);

I think we shouldn't call .fields twice.

ptomato

comment created time in 2 days

Pull request review commenttc39/proposal-temporal

Calendar.fields method

 export class Date {       calendar = GetSlot(this, CALENDAR);       source = this;     }-    const props = ES.ToPartialRecord(temporalDateLike, ['day', 'era', 'month', 'year']);+    const fieldNames = calendar.fields(['day', 'era', 'month', 'year']);+    const props = ES.ToPartialRecord(temporalDateLike, fieldNames);

This is too trusting of the calendar - should make sure we've got a clean array of strings. (Potentially for followup.)

ptomato

comment created time in 2 days

PullRequestReviewEvent
PullRequestReviewEvent

push eventtc39/proposal-temporal

Deployment Bot (from Travis CI)

commit sha 7ebc182e8c38be63c73c73483c0e281d2235dee1

Deploy tc39/proposal-temporal to github.com/tc39/proposal-temporal.git:gh-pages

view details

push time in 2 days

push eventtc39/proposal-temporal

Aksh Gupta

commit sha ed1d86c68e178701f0d99affe123eab93086746e

Fix regex pattern for timezone offset parsing (#1029)

view details

push time in 2 days

PR merged tc39/proposal-temporal

Fix regex pattern for timezone offset parsing awaiting-author

Fixes #1002

+3 -3

2 comments

1 changed file

akshgpt7

pr closed time in 2 days

issue closedtc39/proposal-temporal

Polyfill Temporal.Instant timezone offset parsing

The Temporal.Instant.from function may not be correctly handling input without a time zone offset. Example:

Temporal.Instant.from("2020-01-02T03:04:05").toJSON()

Expected: some type of Error thrown because no time zone offset was specified
Actual: "2020-01-01T22:04Z"

It appears to be parsing the seconds ("05") as the time zone offset. Basically, parsing the above example the same as "2020-01-02T03:04+05".

I think the cause is in polyfill/lib/regex.mjs, where it uses a character class of [+-\u2212] in the offset regular expressions. The minus sign is not escaped (and is not the last character in the character class), so it's probably interpreted as a range between '+' and '\u2212'. Which would match almost any character, including ":" in the above example.

closed time in 2 days

22222
PullRequestReviewEvent

push eventtc39/proposal-temporal

Deployment Bot (from Travis CI)

commit sha 6eacca5899caf5efc9197596cb21b9f7512819a8

Deploy tc39/proposal-temporal to github.com/tc39/proposal-temporal.git:gh-pages

view details

push time in 2 days

push eventtc39/proposal-temporal

Philip Chimento

commit sha 7bd137c6277b10f4b19e4ffbd285827a1e7f2bd3

Use ES.ToTemporalCalendar in more places

view details

Philip Chimento

commit sha 6e7c4107503259dc42563b145a6e3070417561aa

Refactor from() functions into ES.ToTemporalFoo operations These operations will be used elsewhere to convert arguments to other methods, so change them into abstract operations. See: #592

view details

Philip Chimento

commit sha ef4a67d14533f165e05965ae2c650c6fb05f2596

Allow strings and property bags in compare() functions See: #592

view details

Philip Chimento

commit sha a882ca9c7a90cfcdee647e3edf3a75c5c2e9caff

Allow strings in add() and subtract() methods Property bags were already allowed. See: #592

view details

Philip Chimento

commit sha 10a441b7e3df4026befe7be53a33b1fa16008340

Allow strings and property bags in difference() methods See: #592

view details

Philip Chimento

commit sha 3f21dd6e0654e56a8dd409e7910e608c7e0032e6

Allow strings and property bags in equals() methods See: #592

view details

Philip Chimento

commit sha 6f1b23e2118d894cd7408106926e05342e98909d

Allow strings and property bags in toDateTime() methods Also in toZonedDateTime() methods in the documentation, but those are not implemented yet. See: #592

view details

Philip Chimento

commit sha 23ce59f41c4d039e7e66ad5e008ba91d0121b8b4

Allow strings and property bags in TimeZone methods Strings are allowed in the methods that have a Temporal.Instant argument, and both strings and property bags are allowed in the methods that have a Temporal.DateTime argument. See: #592

view details

push time in 2 days

delete branch tc39/proposal-temporal

delete branch : 592-allow-strings-after-all

delete time in 2 days

PR merged tc39/proposal-temporal

Reviewers
Allow strings and property bags as arguments

As per the latest decisions, strings are allowed everywhere that Temporal objects are expected as arguments (and property bags are allowed as well except for places that expect a Temporal.Instant.)

Closes: #592

+1134 -716

1 comment

65 changed files

ptomato

pr closed time in 2 days

issue closedtc39/proposal-temporal

Reconsider allowing strings in withDate() and withTime()?

As noted by @ptomato in https://github.com/tc39/proposal-temporal/issues/240#issuecomment-614936470:

There's a lot of Temporal.Something.from() involved, making for long lines. For example, to take a DateTime and get midnight on that day, it's either dateTime.getDate().withTime(Temporal.Time.from('00:00')) (or, even longer if you want to avoid the from(), dateTime.with({ hour: 0, minute: 0, second: 0, microsecond: 0, millisecond: 0, nanosecond: 0 })). It might be more readable to reverse our decision not to take strings in methods like withTime(), plus(), etc.

I agreed in a follow-up comment:

Reading all the .from() code makes the API look very cumbersome to work with, which may hinder adoption. Playing around with some use cases in the console, I found myself automatically writing things like date.withTime('10:00') and getting annoyed that it doesn't work.

From what I can tell, the decision to not allow strings in date.withTime() happened in #237, but I'm still not sure on the rationale for doing so. A lot of the cookbook examples look more complicated than they should with the current spec. I know which one of these two options I'd prefer to read in a codebase:

const date = Temporal.now.date();
date.withTime(Temporal.Time.from('09:00'));
date.withTime('09:00');

The main reason I think it should be reconsidered is that Absolute.prototype.inTimeZone() accepts a TimeZone OR a string (likewise for DateTime). So if I can write abs.inTimeZone('Australia/Lord_Howe') instead of abs.inTimeZone(Temporal.TimeZone.from('Australia/Lord_Howe')), why can't I write date.withTime('13:45') or time.withDate('2020-11-01')?

Edit for clarity after comments: My proposal is to allow whatever is allowed in the first argument of Date.from() or Time.from(), respectively. This would include the correct Temporal objects (as it is now), strings, and property bags. Extra option arguments (e.g. overflow) would not be allowed — anyone wanting to use them can use the current technique of constructing the object via .from() directly.

closed time in 2 days

gilmoreorless

push eventtc39/proposal-temporal

Deployment Bot (from Travis CI)

commit sha 3bbd1d0783ebf2e5d17cbb3ce85247f061895374

Deploy tc39/proposal-temporal to github.com/tc39/proposal-temporal.git:gh-pages

view details

push time in 2 days

delete branch tc39/proposal-temporal

delete branch : typos

delete time in 2 days

push eventtc39/proposal-temporal

Ms2ger

commit sha c62e76db66e4e62cf483cd82f627e1024c78f599

Fix some typos.

view details

push time in 2 days

PR merged tc39/proposal-temporal

Fix some typos.
+2 -2

1 comment

1 changed file

Ms2ger

pr closed time in 2 days

push eventtc39/proposal-temporal

Philip Chimento

commit sha 6f643bb0718bb59daeffbbf130e6c7ad0a469be3

Allow strings in add() and subtract() methods Property bags were already allowed. See: #592

view details

Philip Chimento

commit sha 245e266f610b1d708ac69b1f5dd1658e0df76fd0

Allow strings and property bags in difference() methods See: #592

view details

Philip Chimento

commit sha a11c37033831d19d26846f8ab1376c7757b47e38

Allow strings and property bags in equals() methods See: #592

view details

Philip Chimento

commit sha df8993f7efc8055b73ed17df7fc81374d8ca4487

Allow strings and property bags in toDateTime() methods Also in toZonedDateTime() methods in the documentation, but those are not implemented yet. See: #592

view details

Philip Chimento

commit sha 767b30c37698a56c249a79b86c5d7f627cb948c7

Allow strings and property bags in TimeZone methods Strings are allowed in the methods that have a Temporal.Instant argument, and both strings and property bags are allowed in the methods that have a Temporal.DateTime argument. See: #592

view details

push time in 2 days

PR opened tc39/proposal-temporal

Fix some typos.
+2 -2

0 comment

1 changed file

pr created time in 2 days

push eventtc39/proposal-temporal

Philip Chimento

commit sha 20810a161ba0e6e325cb7886161693f15416ff45

Make ParseISODateTime return offset and ianaName separately Previously it would return an object with 'offset' and 'ianaName' properties and also a 'zone' property which was equal to 'ianaName' if present, and 'offset' if not. This is no longer always the preferred order due to the options in Temporal.ZonedDateTime.from(), so just have it return each property separately if it is present, and implement the preferred order on the caller's end.

view details

Philip Chimento

commit sha 567fb6f1e1208f4db42549c97813560c5026cd5c

Be consistent in calendar return from ParseISODateTime The time zone properties are undefined if not present, not null, and the spec also has the calendar field of the record being undefined if not present.

view details

Philip Chimento

commit sha cb2ce7968fee193d7f4ed7fd7a0325241eb203ca

Allow ISO strings with bracketed time zone but no offset Previously we considered a "time zone part" to be an offset plus an optional bracketed name. Now an ISO string may have either of an "offset part" and "time zone name part", independently of each other. Closes: #933

view details

Philip Chimento

commit sha f198ce1fb6018a6e7ea0643d5ac6e8fd99982632

Fix typo in spec

view details

Philip Chimento

commit sha 013a99bf4b8876ae57ec5b708e38ab343291cb83

Accept strings in with() methods In Date.with(), DateTime.with(), and Time.with() (and in the future in ZonedDateTime.with(),) we now accept strings as well as property bags. The strings are parsed as if with ZonedDateTime.from(), Date.from(), DateTime.from(), and Time.from() in order, with the stipulation that Date.from() is skipped if a time part is present in the string. (Otherwise you would never get a DateTime since Date.from(YYYY-MM-DDTHH:MM:SS) gives you YYYY-MM-DD.) The useful reasons to do this are DateTime.with(dateString), DateTime.with(timeString), ZonedDateTime.with(dateString), ZonedDateTime.with(timeString), and ZonedDateTime.with(dateTimeString). However, for the sake of consistency, we allow it as much as possible in other cases. Cases were it is not allowed are, YearMonth.with() and MonthDay.with(), which cannot accept calendars in their property bags, so passing other Temporal objects there is not allowed in the first place; and YYYY-MM and MM-DD strings, which are ambiguous with HHMM-ZZ and HH-ZZ. Closes: #934

view details

Philip Chimento

commit sha 660cd1b370dffe3f77277356f61155835a07cff6

Allow property bags in Temporal.Calendar.from() These are kept distinct from plain-object custom calendars by the absence of a 'calendar' property. This way, any Temporal type that carries a calendar, as well as any property bag of that type, can be passed to Temporal.Calendar.from(). See: #925

view details

Philip Chimento

commit sha 3d9c158385f42f81e57eecd398ce5382eef5b042

Allow property bags in Temporal.TimeZone.from() These are kept distinct from plain-object custom time zones by the absence of a 'timeZone' property. This way, any Temporal type that carries a time zone (currently only ZonedDateTime), as well as any ZonedDateTime property bag, can be passed to Temporal.TimeZone.from(). See: #925

view details

Philip Chimento

commit sha 6c2b6ff852e2249340e747787dfe5618d7471d6f

Use ES.ToTemporalCalendar in more places

view details

Philip Chimento

commit sha 78c8641fd672cd3164ffd1eaf81fcf4fd86e12c9

Refactor from() functions into ES.ToTemporalFoo operations These operations will be used elsewhere to convert arguments to other methods, so change them into abstract operations. See: #592

view details

Philip Chimento

commit sha feff5190b4283f637101f0cad801e881ff6adc03

Allow strings and property bags in compare() functions See: #592

view details

Philip Chimento

commit sha c8126a110e791ff1c2b818d31cc711032964e753

Allow strings in add() and subtract() methods Property bags were already allowed. See: #592

view details

Philip Chimento

commit sha 926305080e8288f72efc9fa1d4008eda450aa059

Allow strings and property bags in difference() methods See: #592

view details

Philip Chimento

commit sha af2bad195f616d78ac73333adf9f766c22dc10a3

Allow strings and property bags in equals() methods See: #592

view details

Philip Chimento

commit sha e7afc19c156f3a71fff01c84cf40ca5d36f56a97

Allow strings and property bags in toDateTime() methods Also in toZonedDateTime() methods in the documentation, but those are not implemented yet. See: #592

view details

Philip Chimento

commit sha d1e7ed2b37c10522693d61c1167a05fe60150f2b

Allow strings and property bags in TimeZone methods Strings are allowed in the methods that have a Temporal.Instant argument, and both strings and property bags are allowed in the methods that have a Temporal.DateTime argument. See: #592

view details

push time in 2 days

create barnchtc39/proposal-temporal

branch : typos

created branch time in 2 days

PullRequestReviewEvent

Pull request review commenttc39/proposal-temporal

Allow strings and property bags as arguments

 Effectively, this is the canonicalized version of whatever `timeZoneIdentifier`  ## Methods -### timeZone.**getOffsetNanosecondsFor**(_instant_: Temporal.Instant) : number+### timeZone.**getOffsetNanosecondsFor**(_instant_: Temporal.Instant | string) : number

#1030

ptomato

comment created time in 2 days

PullRequestReviewEvent

issue openedtc39/proposal-temporal

Re-re-reconsider accepting non-normalized arguments in timezone methods

See comments in https://github.com/tc39/proposal-temporal/pull/1015#discussion_r508373472 . I don't think timezone is particularly less advanced than calendar, in any case.

created time in 2 days

push eventtc39/proposal-temporal

Deployment Bot (from Travis CI)

commit sha 7c58a1f34d045aca0a8ff48cd965669b67ed11e7

Deploy tc39/proposal-temporal to github.com/tc39/proposal-temporal.git:gh-pages

view details

push time in 2 days

push eventtc39/proposal-temporal

Philip Chimento

commit sha 660cd1b370dffe3f77277356f61155835a07cff6

Allow property bags in Temporal.Calendar.from() These are kept distinct from plain-object custom calendars by the absence of a 'calendar' property. This way, any Temporal type that carries a calendar, as well as any property bag of that type, can be passed to Temporal.Calendar.from(). See: #925

view details

Philip Chimento

commit sha 3d9c158385f42f81e57eecd398ce5382eef5b042

Allow property bags in Temporal.TimeZone.from() These are kept distinct from plain-object custom time zones by the absence of a 'timeZone' property. This way, any Temporal type that carries a time zone (currently only ZonedDateTime), as well as any ZonedDateTime property bag, can be passed to Temporal.TimeZone.from(). See: #925

view details

push time in 2 days

delete branch tc39/proposal-temporal

delete branch : 925-valid-timezone-calendar-objects

delete time in 2 days

issue closedtc39/proposal-temporal

How to handle this code? Temporal.TimeZone.from({timeZone: 'Asia/Tokyo'})

Given our new pattern (#889) for conversion methods where multiple args go into a property bag, we can expect that at least some users will use this pattern in places where we currently don't expect it. Like this:

tz = Temporal.TimeZone.from({timeZone: 'Asia/Tokyo'})

The current behavior of this code is bad. It returns without an exception but will fail downstream with a confusing error if you try to use the result for anything, e.g.

tz = Temporal.TimeZone.from({timeZone: 'Asia/Tokyo'});  // expected: throw
dt = Temporal.DateTime.from('2020-10-01T00:00');
dt.toAbsolute(tz);
// => 
// timezone.mjs:101 Uncaught TypeError: this.getPossibleAbsolutesFor is not a function
//    at Object.getAbsoluteFor (timezone.mjs:101)
//    at Object.Call (Call.js:12)
//    at Object.GetTemporalAbsoluteFor (ecmascript.mjs:745)
//    at DateTime.toAbsolute (datetime.mjs:578)
//    at <anonymous>:3:4

So it's a polyfill bug that needs fixing.

That said, in our decisions around #889 and #592, we agreed that all places in Temporal that currently accept a Temporal instance would be retrofitted to also support a string or a property bag.

But we didn't discuss how to handle places in Temporal where a string and Temporal instance is currently accepted but not a property bag. For example: TimeZone.from and Calendar.from. This is essentially the inverse case of methods like plus that currently accept a property bag or an instance but not a string.

My proposal would be to support a property bag input for those places too, so there's one consistent pattern used everywhere, that anywhere you can pass a Temporal object (including TimeZone and Calendar), then a string and a property bag should be accepted. I'm not saying we should promote this syntax, only that some users will probably assume it works and I don't see a downside from having consistency everywhere.

It also mirrors what we're discussing for handling the advice we give to developers about how to handle ISO strings, e.g.

iso = '2020-09-20T12:02:15.984303069-07:00[America/Los_Angeles]';
ldt = Temporal.LocalDateTime.from(iso);
dt = Temporal.DateTime.from(iso);
date = Temporal.Date.from(iso);
tz = Temporal.TimeZone.from(iso);
fields = ldt.getFields();
dt = Temporal.DateTime.from(fields);
date = Temporal.Date.from(fields);
tz = Temporal.TimeZone.from(fields);   // why shouldn't this work too?

I'd argue that for Calendar and TimeZone, we should accept two variants of the property bag: one for id and one for what we call the field in getFields() results from other types. Examples:

Temporal.TimeZone.from({timeZone: 'Asia/Tokyo'});
Temporal.TimeZone.from({id: 'Asia/Tokyo'});
Temporal.Calendar.from({calendar: 'japanese'});
Temporal.Calendar.from({id: 'japanese'});

If the plan above doesn't have consensus, then my alternate proposal would be that passing a property bag to those methods should throw.

closed time in 2 days

justingrant
PullRequestReviewEvent

push eventtc39/proposal-temporal

Deployment Bot (from Travis CI)

commit sha bc2e24b359a2a7642be259768de9995ec5431a8f

Deploy tc39/proposal-temporal to github.com/tc39/proposal-temporal.git:gh-pages

view details

push time in 2 days

push eventtc39/proposal-temporal

Philip Chimento

commit sha f198ce1fb6018a6e7ea0643d5ac6e8fd99982632

Fix typo in spec

view details

Philip Chimento

commit sha 013a99bf4b8876ae57ec5b708e38ab343291cb83

Accept strings in with() methods In Date.with(), DateTime.with(), and Time.with() (and in the future in ZonedDateTime.with(),) we now accept strings as well as property bags. The strings are parsed as if with ZonedDateTime.from(), Date.from(), DateTime.from(), and Time.from() in order, with the stipulation that Date.from() is skipped if a time part is present in the string. (Otherwise you would never get a DateTime since Date.from(YYYY-MM-DDTHH:MM:SS) gives you YYYY-MM-DD.) The useful reasons to do this are DateTime.with(dateString), DateTime.with(timeString), ZonedDateTime.with(dateString), ZonedDateTime.with(timeString), and ZonedDateTime.with(dateTimeString). However, for the sake of consistency, we allow it as much as possible in other cases. Cases were it is not allowed are, YearMonth.with() and MonthDay.with(), which cannot accept calendars in their property bags, so passing other Temporal objects there is not allowed in the first place; and YYYY-MM and MM-DD strings, which are ambiguous with HHMM-ZZ and HH-ZZ. Closes: #934

view details

push time in 2 days

delete branch tc39/proposal-temporal

delete branch : 934-strings-in-with-methods

delete time in 2 days

PR merged tc39/proposal-temporal

Reviewers
Accept strings in with() methods

Closes: #934

+142 -17

1 comment

17 changed files

ptomato

pr closed time in 2 days

issue closedtc39/proposal-temporal

Make with() methods accept an ISO string

As per the September 18 meeting, although we have gone back and forth on this several times, in the interest of brevity we are going to allow all types' with() methods to accept an ISO string. Like relativeTo in the rounding methods, it will attempt to be parsed as LocalDateTime, Absolute, DateTime, Date, Time, YearMonth, MonthDay in order.

closed time in 2 days

ptomato
PullRequestReviewEvent

push eventtc39/proposal-temporal

Deployment Bot (from Travis CI)

commit sha 55bd43d3d72b1ad1475b16cff81e52f9556da343

Deploy tc39/proposal-temporal to github.com/tc39/proposal-temporal.git:gh-pages

view details

push time in 2 days

push eventtc39/proposal-temporal

Philip Chimento

commit sha 20810a161ba0e6e325cb7886161693f15416ff45

Make ParseISODateTime return offset and ianaName separately Previously it would return an object with 'offset' and 'ianaName' properties and also a 'zone' property which was equal to 'ianaName' if present, and 'offset' if not. This is no longer always the preferred order due to the options in Temporal.ZonedDateTime.from(), so just have it return each property separately if it is present, and implement the preferred order on the caller's end.

view details

Philip Chimento

commit sha 567fb6f1e1208f4db42549c97813560c5026cd5c

Be consistent in calendar return from ParseISODateTime The time zone properties are undefined if not present, not null, and the spec also has the calendar field of the record being undefined if not present.

view details

Philip Chimento

commit sha cb2ce7968fee193d7f4ed7fd7a0325241eb203ca

Allow ISO strings with bracketed time zone but no offset Previously we considered a "time zone part" to be an offset plus an optional bracketed name. Now an ISO string may have either of an "offset part" and "time zone name part", independently of each other. Closes: #933

view details

push time in 2 days

delete branch tc39/proposal-temporal

delete branch : 933-iso-string-no-offset

delete time in 2 days

issue closedtc39/proposal-temporal

Decide whether ISO string with bracketed time zone name but no offset is valid

The champions group is not all agreed on whether the string '2020-09-18T14:26[America/New_York]' is well-formed.

Various notes:

  • The [America/New_York] part is not standard according to ISO either way. We are trying to standardize it. We would want to avoid accepting something that might not be standardized.
  • What do userland libraries and other languages do with a string like this?

closed time in 2 days

ptomato
PullRequestReviewEvent
PullRequestReviewEvent

issue commenttc39/proposal-temporal

Document time zone used for Instant in Intl.DateTimeFormat

Also, in the current Intl section of the spec, dateTimeFormat.[[TimeZone]] is only taken into account in the non-temporal case. Sounds like we should fix that.

Ayc0

comment created time in 2 days

issue commenttc39/proposal-temporal

Document time zone used for Instant in Intl.DateTimeFormat

Yeah, ZonedDateTime hasn't landed in the polyfill yet. Soon(TM).

Ayc0

comment created time in 2 days

PullRequestReviewEvent

Pull request review commenttc39/proposal-temporal

toString() precision

 <h1>ToTemporalRoundingIncrement ( _normalizedOptions_, _dividend_, _inclusive_ )     </emu-alg>   </emu-clause> +  <emu-clause id="sec-temporal-tosecondsstringprecision" aoid="ToSecondsStringPrecision">+    <h1>ToSecondsStringPrecision ( _normalizedOptions_ )</h1>+    <p>+      The abstract operation ToSecondsStringPrecision combines the values of the options `smallestUnit` and `fractionalSecondDigits` to yield a precision for printing minutes and seconds to a string, and a rounding unit and increment.+      The precision may be an integer 0 through 9 signifying a number of digits after the decimal point in the seconds, the string *"minute"* signifying not to print seconds at all, or the string *"auto"* signifying to drop trailing zeroes after the decimal point.+    </p>+    <emu-alg>+      1. Let _smallestUnit_ be ? GetOption(_normalizedOptions_, *"smallestUnit"*, *"string"*, « *"minute"*, *"second"*, *"millisecond"*, *"microsecond"*, *"nanosecond"*, *"minutes"*, *"seconds"*, *"milliseconds"*, *"microseconds"*, *"nanoseconds"* », *undefined*).+      1. If the value of _smallestUnit_ is in the Plural column of <emu-xref href="#table-temporal-singular-and-plural-units"></emu-xref>, then+        1. Set _smallestUnit_ to the corresponding Singular value of the same row.+      1. If _smallestUnit_ is *"minute"*, then+        1. Return the new Record {+            [[Precision]]: *"minute"*,+            [[Unit]]: *"minute"*,+            [[Increment]]: 1+          }.+      1. If _smallestUnit_ is *"second"*, then+        1. Return the new Record {+            [[Precision]]: 0,+            [[Unit]]: *"second"*,+            [[Increment]]: 1+          }.+      1. If _smallestUnit_ is *"millisecond"*, then+        1. Return the new Record {+            [[Precision]]: 3,+            [[Unit]]: *"millisecond"*,+            [[Increment]]: 1+          }.+      1. If _smallestUnit_ is *"microsecond"*, then+        1. Return the new Record {+            [[Precision]]: 6,+            [[Unit]]: *"microsecond"*,+            [[Increment]]: 1+          }.+      1. If _smallestUnit_ is *"nanosecond"*, then+        1. Return the new Record {+            [[Precision]]: 9,+            [[Unit]]: *"nanosecond"*,+            [[Increment]]: 1+          }.+      1. Let _digits_ be ? GetStringOrNumberOption(_normalizedOptions_, *"fractionalSecondDigits"*, « *"auto"* », 0, 9, *"auto"*).

Maybe it would have reduced my earlier confusion if there was a step above this saying "Assert: smallestUnit is undefined."

ptomato

comment created time in 2 days

Pull request review commenttc39/proposal-temporal

toString() precision

 <h1>GetNumberOption ( _options_, _property_, _minimum_, _maximum_, _fallback_ )<     </emu-alg>   </emu-clause> +  <emu-clause id="sec-getstringornumberoption" aoid="GetStringOrNumberOption">+    <h1>GetStringOrNumberOption ( _options_, _property_, _stringValues_, _minimum_, _maximum_, _fallback_ )</h1>+    <p>+      The abstract operation GetStringOrNumberOption extracts the value of the property named _property_ from the provided _options_ object.+      If the value is a Number value, the operation checks whether it is in the allowed range.+      Otherwise, the operation converts it to a string and checks whether it is one of a List of allowed _stringValues_, and fills in a _fallback_ value if necessary.+      If _stringValues_ is *undefined*, there is no fixed set of values and any is permitted.+    </p>+    <emu-alg>+      1. Assert: Type(_options_) is Object.+      1. Let _value_ be ? Get(_options_, _property_).+      1. If _value_ is *undefined*, return _fallback_.+      1. Set _value_ to ? ToPrimitive(_value_, ~number~).+      1. If Type(_value_) is Number, then+        1. If _value_ is *NaN*, or _value_ &lt; _minimum_, or _value_ &gt; _maximum_, throw a *RangeError* exception.+        1. Return floor(ℝ(_value_)).+      1. Set _value_ to ? ToString(_value_).

Calling ToString on the result of ToPrimitive seems like a bad idea to me. If we don't have precedent on the TC39 side, I'd like to follow WebIDL precedent, which comes down to just dropping to ToPrimitive call (so use the number if Type is number, and ToString otherwise).

ptomato

comment created time in 2 days

PullRequestReviewEvent

issue commenttc39/proposal-temporal

Inconsistency between Instant and Intl.DateTimeFormat

It shouldn't be 2AM - Instant doesn't remember that the Sydney time zone was involved, so it only stores the UTC date/time: 2020-04-04T15:00Z. I don't think there's then supposed to be a conversion to local time, though. (The polyfill only does that because it defers to the existing in-browser implementation, which does; the spec doesn't, AFAICT.)

Ayc0

comment created time in 3 days

issue openedtc39/proposal-temporal

Intl section needs to use ISO-prefixed internal slots

date.[[ISOYear]] rather than date.[[Year]], etc.

created time in 3 days

issue commenttc39/proposal-temporal

Instant.toLocaleString() throws TypeError: use compare() or equals() to compare Temporal.Instant

Thanks for the report. I can't repro on https://tc39.es/proposal-temporal/docs/ , so not sure what's going on.

Ayc0

comment created time in 3 days

Pull request review commenttc39/proposal-temporal

Allow strings and property bags as arguments

 export const ES = ObjectAssign({}, ES2020, {   ToTemporalYearMonthRecord: (bag) => {     return ES.ToRecord(bag, [['era', undefined], ['month'], ['year']]);   },++  ToTemporalDate: (item, constructor, overflow = 'constrain') => {+    let result;+    if (ES.Type(item) === 'Object') {+      if (ES.IsTemporalDate(item)) return item;+      let calendar = item.calendar;+      if (calendar === undefined) calendar = GetISO8601Calendar();

Note that ecmascript.js currently isn't supposed to use GetISO8601Calendar; #1008.

ptomato

comment created time in 3 days

Pull request review commenttc39/proposal-temporal

Allow strings and property bags as arguments

 dt = Temporal.DateTime.from('1995-12-07T03:24:30.000003500[c=japanese]'); dt.withCalendar('iso8601'); // => 1995-12-07T03:24:30.000003500 ``` -### datetime.**add**(_duration_: object, _options_?: object) : Temporal.DateTime+### datetime.**add**(_duration_: Temporal.Duration | object | string, _options_?: object) : Temporal.DateTime  **Parameters:** -- `duration` (object): A `Temporal.Duration` object or a duration-like object.+- `duration` (`Temporal.Duration` or value convertibel to one): The duration to add.

convertible

ptomato

comment created time in 3 days

Pull request review commenttc39/proposal-temporal

Allow strings and property bags as arguments

 Effectively, this is the canonicalized version of whatever `timeZoneIdentifier`  ## Methods -### timeZone.**getOffsetNanosecondsFor**(_instant_: Temporal.Instant) : number+### timeZone.**getOffsetNanosecondsFor**(_instant_: Temporal.Instant | string) : number

I'm not convinced for the TimeZone methods. Authors should generally not call those, so there's no improved ergonomics. On the other hand, it's easy to forget this extra step in custom time zones, especially since Temporal itself will never pass non-normalized arguments, leading to surprising bugs when someone calls the methods directly for some weird reason.

ptomato

comment created time in 3 days

Pull request review commenttc39/proposal-temporal

Allow strings and property bags as arguments

 export class Date {       } else {         let calendar = item.calendar;         if (calendar === undefined) calendar = GetISO8601Calendar();-        calendar = TemporalCalendar.from(calendar);+        calendar = ES.CalendarFrom(calendar);

CalendarFrom only accepts strings. You may be looking for ToTemporalCalendar.

ptomato

comment created time in 3 days

PullRequestReviewEvent
PullRequestReviewEvent

push eventtc39/proposal-temporal

Deployment Bot (from Travis CI)

commit sha be97ade8cf084bf525f2b953f0c41e79331636d8

Deploy tc39/proposal-temporal to github.com/tc39/proposal-temporal.git:gh-pages

view details

push time in 3 days

push eventtc39/proposal-temporal

Philip Chimento

commit sha 6e36d939859dd61c0f1482a1171c146c96fbb3cf

Add skeleton Calendar test We did not have one of these yet. Add it and check for all the methods and properties on the Calendar constructor and prototype.

view details

Philip Chimento

commit sha b0ac231af7502b79963df90af8308255cafc1f34

Allow ISO strings in Temporal.Calendar.from() This brings the behaviour in line with Temporal.TimeZone. If a calendar annotation is not given in the ISO string, then the ISO calendar is assumed. Closes: #862

view details

Philip Chimento

commit sha f4c93dce6c979f8b21d977e9976490ca02275287

Make CompareTemporalInstant take epoch nanoseconds If this operation takes epoch nanoseconds instead of a Temporal.Instant instance, then it can be reused for ZonedDateTime.compare().

view details

Philip Chimento

commit sha e792594197e4ed35368dc0b82bcc79438cfdca5e

Add calendar argument to TemporalInstantToString GetTemporalDateTimeFor also has a calendar argument, so this was a bug in the spec.

view details

Philip Chimento

commit sha 3e115cf457e4d7791c5dfad890dba2adb7f76cd1

Use ES.CalendarFrom in more places

view details

Philip Chimento

commit sha 01c9205e9e04ff47c547886485bc35ef0103eeb7

Refactor from() functions into ES.ToTemporalFoo operations These operations will be used elsewhere to convert arguments to other methods, so change them into abstract operations. See: #592

view details

Philip Chimento

commit sha 70e1b2077cf3f1d2c7484a15b53043cc8c38accf

Allow strings and property bags in compare() functions See: #592

view details

Philip Chimento

commit sha adf6c87a0fbeb5a3eace2a789afd7af189f6699e

Allow strings in add() and subtract() methods Property bags were already allowed. See: #592

view details

Philip Chimento

commit sha 00b0580e0a244e19ab5e1975f7fe3f057c0be77c

Allow strings and property bags in difference() methods See: #592

view details

Philip Chimento

commit sha 1f5178968dd98060dc80fdf4ed5c390bc0c5b202

Allow strings and property bags in equals() methods See: #592

view details

Philip Chimento

commit sha bb0208f51e97f4171f0b7a539d9535f4232b504e

Allow strings and property bags in toDateTime() methods Also in toZonedDateTime() methods in the documentation, but those are not implemented yet. See: #592

view details

Philip Chimento

commit sha 212b0460ba671fc10251a6aba859a98d4d1b0502

Allow strings and property bags in TimeZone methods Strings are allowed in the methods that have a Temporal.Instant argument, and both strings and property bags are allowed in the methods that have a Temporal.DateTime argument. See: #592

view details

push time in 3 days

push eventtc39/proposal-temporal

Philip Chimento

commit sha f4c93dce6c979f8b21d977e9976490ca02275287

Make CompareTemporalInstant take epoch nanoseconds If this operation takes epoch nanoseconds instead of a Temporal.Instant instance, then it can be reused for ZonedDateTime.compare().

view details

Philip Chimento

commit sha e792594197e4ed35368dc0b82bcc79438cfdca5e

Add calendar argument to TemporalInstantToString GetTemporalDateTimeFor also has a calendar argument, so this was a bug in the spec.

view details

push time in 3 days

delete branch tc39/proposal-temporal

delete branch : spec-improvements-for-zoneddatetime

delete time in 3 days

PR merged tc39/proposal-temporal

Reviewers
Spec improvements

A couple of improvements I made while working on ZonedDateTime spec.

+13 -14

1 comment

1 changed file

ptomato

pr closed time in 3 days

PullRequestReviewEvent

Pull request review commenttc39/proposal-temporal

toString() precision

 <h1>MaximumTemporalDurationRoundingIncrement ( _unit_ )</h1>   </emu-clause>    <emu-clause id="sec-temporal-formatsecondsstringpart" aoid="FormatSecondsStringPart">-    <h1>FormatSecondsStringPart ( _second_, _millisecond_, _microsecond_, _nanosecond_ )</h1>-    <emu-alg>-      1. If _second_, _millisecond_, _microsecond_, and _nanosecond_ are all 0, then-        1. Return `""`.-      1. Let _nanos_, _micros_, and _millis_ be `""`.-      1. If _nanosecond_ is not 0, then-        1. Set _nanos_ to _nanosecond_ formatted as a three-digit decimal number, padded to the left with zeroes if necessary.-        1. Set _micros_ and _millis_ to `"000"`.-      1. If _microsecond_ is not 0, then-        1. Set _micros_ be _microsecond_ formatted as a three-digit decimal number, padded to the left with zeroes if necessary.-        1. Set _millis_ to `"000"`.-      1. If _millisecond_ is not 0, then-        1. Set _millis_ to _millisecond_ formatted as a three-digit decimal number, padded to the left with zeroes if necessary.-      1. Let _decimal_ be the string-concatenation of _millis_, _micros_, and _nanos_.-      1. Let _result_ be _second_ formatted as a two-digit decimal number, padded to the left with a zero if necessary.-      1. If _decimal_ is not empty, then-        1. Set _result_ to the string-concatenation of _result_, the code unit 0x002E (FULL STOP), and _decimal_.-      1. Return the string-concatenation of the code unit 0x003A (COLON) and _result_.+    <h1>FormatSecondsStringPart ( _second_, _millisecond_, _microsecond_, _nanosecond_, _precision_ )</h1>+    <emu-alg>+      1. If _precision_ is *"minute"*, return *""*.+      1. Let _secondsString_ be the string-concatenation of the code unit 0x003A (COLON) and _second_ formatted as a two-digit decimal number, padded to the left with zeroes if necessary.+      1. Let _fraction_ be _millisecond_ × 10<sup>6</sup> + _microsecond_ × 10<sup>3</sup> + _nanosecond_.+      1. If _precision_ is *"auto"*, then+        1. If _fraction_ = 0, return _secondsString_.

"is"

ptomato

comment created time in 3 days

Pull request review commenttc39/proposal-temporal

toString() precision

 export const ES = ObjectAssign({}, ES2020, {     }     return increment;   },+  ToSecondsStringPrecision: (options) => {+    const singular = new Map([+      ['minutes', 'minute'],+      ['seconds', 'second'],+      ['milliseconds', 'millisecond'],+      ['microseconds', 'microsecond'],+      ['nanoseconds', 'nanosecond']+    ]);+    const allowed = new Set(['minute', 'second', 'millisecond', 'microsecond', 'nanosecond']);+    let smallestUnit = ES.GetOption(options, 'smallestUnit', [...allowed, ...singular.keys()], undefined);+    if (singular.has(smallestUnit)) smallestUnit = singular.get(smallestUnit);+    switch (smallestUnit) {+      case 'minute':+        return { precision: 'minute', unit: 'minute', increment: 1 };+      case 'second':+        return { precision: 0, unit: 'second', increment: 1 };+      case 'millisecond':+        return { precision: 3, unit: 'millisecond', increment: 1 };+      case 'microsecond':+        return { precision: 6, unit: 'microsecond', increment: 1 };+      case 'nanosecond':+        return { precision: 9, unit: 'nanosecond', increment: 1 };+      default: // fall through if option not given+    }+    let digits = options.fractionalSecondDigits;+    if (digits === undefined || digits === 'auto') return { precision: 'auto', unit: 'nanosecond', increment: 1 };+    digits = ES.ToNumber(digits);+    if (NumberIsNaN(digits) || digits < 0 || digits > 9) {+      throw new RangeError(`fractionalSecondDigits must be 'auto' or 0 through 9, not ${digits}`);+    }+    const precision = MathFloor(digits);

I don't think it makes sense to disallow 9.1 but support 8.9. Why not just use ToInteger?

ptomato

comment created time in 3 days

PullRequestReviewEvent
more