You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/README.md
+15-15Lines changed: 15 additions & 15 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -33,25 +33,25 @@ Converting between such types and exact time types (`Temporal.Instant` and `Temp
33
33
34
34
Several important concepts are explained elsewhere: [exact time, wall-clock time, time zones, DST, handling ambiguity, and more](./ambiguity.md).
35
35
36
-
### **Temporal.now**
37
-
38
-
-`Temporal.now.instant()` - get the exact time since [Unix epoch](https://en.wikipedia.org/wiki/Unix_time)
39
-
-`Temporal.now.timeZone()` - get the current system time zone
40
-
-`Temporal.now.zonedDateTime(calendar)` - get the current date and wall-clock time in the system time zone and specified calendar
41
-
-`Temporal.now.zonedDateTimeISO()` - get the current date and wall-clock time in the system time zone and ISO-8601 calendar
42
-
-`Temporal.now.plainDate(calendar)` - get the current date in the system time zone and specified calendar
43
-
-`Temporal.now.plainDateISO()` - get the current date in the system time zone and ISO-8601 calendar
44
-
-`Temporal.now.plainTimeISO()` - get the current wall-clock time in the system time zone and ISO-8601 calendar
45
-
-`Temporal.now.plainDateTime(calendar)` - get the current system date/time in the system time zone, but return an object that doesn't remember its time zone so should NOT be used to derive other values (e.g. 12 hours later) in time zones that use Daylight Saving Time (DST).
46
-
-`Temporal.now.plainDateTimeISO()` - same as above, but return the DateTime in the ISO-8601 calendar
36
+
### **Temporal.Now**
37
+
38
+
-`Temporal.Now.instant()` - get the exact time since [Unix epoch](https://en.wikipedia.org/wiki/Unix_time)
39
+
-`Temporal.Now.timeZone()` - get the current system time zone
40
+
-`Temporal.Now.zonedDateTime(calendar)` - get the current date and wall-clock time in the system time zone and specified calendar
41
+
-`Temporal.Now.zonedDateTimeISO()` - get the current date and wall-clock time in the system time zone and ISO-8601 calendar
42
+
-`Temporal.Now.plainDate(calendar)` - get the current date in the system time zone and specified calendar
43
+
-`Temporal.Now.plainDateISO()` - get the current date in the system time zone and ISO-8601 calendar
44
+
-`Temporal.Now.plainTimeISO()` - get the current wall-clock time in the system time zone and ISO-8601 calendar
45
+
-`Temporal.Now.plainDateTime(calendar)` - get the current system date/time in the system time zone, but return an object that doesn't remember its time zone so should NOT be used to derive other values (e.g. 12 hours later) in time zones that use Daylight Saving Time (DST).
46
+
-`Temporal.Now.plainDateTimeISO()` - same as above, but return the DateTime in the ISO-8601 calendar
Copy file name to clipboardExpand all lines: docs/calendar-draft.md
+21-21Lines changed: 21 additions & 21 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -299,7 +299,7 @@ Here is an illustrated version of this option:
299
299
300
300
### New Factory Methods (Option 6)
301
301
302
-
With this option, separate methods would indicate whether the Full ISO calendar should be used versus a potentially non-ISO calendar. For example, `Temporal.now.plainDateISO` would be added to supplement `Temporal.now.plainDate`. See the full table below.
302
+
With this option, separate methods would indicate whether the Full ISO calendar should be used versus a potentially non-ISO calendar. For example, `Temporal.Now.plainDateISO` would be added to supplement `Temporal.Now.plainDate`. See the full table below.
303
303
304
304
### Methods of Construction
305
305
@@ -312,8 +312,8 @@ The following table describes these semantics. Option 5 is not shown because the
Copy file name to clipboardExpand all lines: docs/calendar-review.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -192,7 +192,7 @@ For example:
192
192
Userland code can completely avoid the use of calendar-specific constants (e.g. 12 months per year) by using these properties.
193
193
- There is never an implicit default calendar system.
194
194
Developers must explicitly decide whether they're using the ISO calendar or another calendar.
195
-
For example, shortcut methods on the `Temporal.now` object are named with an ISO prefix to avoid ambiguity, such as `Temporal.now.zonedDateTimeISO()`.
195
+
For example, shortcut methods on the `Temporal.Now` object are named with an ISO prefix to avoid ambiguity, such as `Temporal.Now.zonedDateTimeISO()`.
196
196
- Temporal never infers a calendar from the user's environment.
197
197
Introducing a calendar system into a program requires a conscious, opt-in decision on the part of the developer of the app, library, or input source.
198
198
@@ -305,11 +305,11 @@ In the end, the champions decided that the subclassing approach brought a high c
305
305
306
306
### Alternative 4: Separate Types for Calendared Dates
307
307
308
-
This approach would mean introducing a new type that carries a date without a calendar system, to supplement the type with the calendar system. Most documentation would recommend the calendar-agnostic type except when calendar-aware logic is necessary. We discuss this approach in more detail as [Option 5 in calendar-draft.md](https://github.com/tc39/proposal-temporal/blob/main/docs/calendar-draft.md#new-non-calendar-types-option-5).
308
+
This approach would mean introducing a new type that carries a date without a calendar system, to supplement the type with the calendar system. Most documentation would recommend the calendar-agnostic type except when calendar-aware logic is necessary. We discuss this approach in more detail as [Option 5 in calendar-draft.md](https://github.com/tc39/proposal-temporal/blob/main/docs/calendar-draft.md#new-non-calendar-types-option-5).
309
309
310
310
We decided against the dual classes approach because:
311
311
312
312
1. If the new type were truly calendar-agnostic, it could not support month and year arithmetic, because doing so would introduce an ISO bias.
313
313
2. If the new type had ISO-like behavior for months and years, then it is no different from PlainDate with an ISO calendar.
314
314
315
-
Note that (2) is true for ECMAScript because it is dynamically typed. Statically typed languages could enforce compile-time type checking for (2) that is not possible in ECMAScript. Note also that clients such as TypeScript can treat PlainDate as having a type parameter corresponding to the calendar system in order to enforce more compile-time type checking of calendar systems. Separate data types are not necessary for that validation.
315
+
Note that (2) is true for ECMAScript because it is dynamically typed. Statically typed languages could enforce compile-time type checking for (2) that is not possible in ECMAScript. Note also that clients such as TypeScript can treat PlainDate as having a type parameter corresponding to the calendar system in order to enforce more compile-time type checking of calendar systems. Separate data types are not necessary for that validation.
0 commit comments