tyler.durden
/
test262
mirror of https://github.com/tc39/test262.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
test262/test/built-ins/Temporal/ZonedDateTime/from/argument-propertybag-calend...

20 lines
608 B
JavaScript
Raw Normal View History

Regularize leap second tests Everywhere an ISO string is accepted in Temporal, a seconds value of :60 should always be coerced to :59, because of how leap seconds are handled in ISO strings. In property bags, a 'seconds: 60' property is not subject to that rule: it should be handled according to the overflow option if there is one. These tests existed already for some types; regularize them and add the ones that didn't exist yet.
2022-04-20 01:38:36 +02:00
// Copyright (C) 2022 Igalia, S.L. All rights reserved.
// This code is governed by the BSD license found in the LICENSE file.
/*---
esid: sec-temporal.zoneddatetime.from
description: Leap second is a valid ISO string for a calendar in a property bag
features: [Temporal]
---*/
const timeZone = new Temporal.TimeZone("UTC");
const calendar = "2016-12-31T23:59:60+00:00[UTC]";
Remove support for nested Temporal calendar property bags Previously, "nested" calendar property bags were unwrapped up to one level. That is, this object: { calendar: { // ...Temporal.Calendar methods } } would not be considered to implement the Calendar protocol, but would have its calendar property used instead, if it were passed to an API that required a Calendar protocol object. These nested property bags are no longer supported. Discussion: https://github.com/tc39/proposal-temporal/issues/2104#issuecomment-1409549753 Corresponding normative PR: https://github.com/tc39/proposal-temporal/pull/2485
2023-01-19 03:01:05 +01:00
const arg = { year: 1970, monthCode: "M01", day: 1, timeZone, calendar };
const result = Temporal.ZonedDateTime.from(arg);
Regularize leap second tests Everywhere an ISO string is accepted in Temporal, a seconds value of :60 should always be coerced to :59, because of how leap seconds are handled in ISO strings. In property bags, a 'seconds: 60' property is not subject to that rule: it should be handled according to the overflow option if there is one. These tests existed already for some types; regularize them and add the ones that didn't exist yet.
2022-04-20 01:38:36 +02:00
assert.sameValue(
Remove support for nested Temporal calendar property bags Previously, "nested" calendar property bags were unwrapped up to one level. That is, this object: { calendar: { // ...Temporal.Calendar methods } } would not be considered to implement the Calendar protocol, but would have its calendar property used instead, if it were passed to an API that required a Calendar protocol object. These nested property bags are no longer supported. Discussion: https://github.com/tc39/proposal-temporal/issues/2104#issuecomment-1409549753 Corresponding normative PR: https://github.com/tc39/proposal-temporal/pull/2485
2023-01-19 03:01:05 +01:00
result.calendarId,
Regularize leap second tests Everywhere an ISO string is accepted in Temporal, a seconds value of :60 should always be coerced to :59, because of how leap seconds are handled in ISO strings. In property bags, a 'seconds: 60' property is not subject to that rule: it should be handled according to the overflow option if there is one. These tests existed already for some types; regularize them and add the ones that didn't exist yet.
2022-04-20 01:38:36 +02:00
"iso8601",
"leap second is a valid ISO string for calendar"
);