@dyadav0607/calendardate 0.1.0 → 0.1.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "@dyadav0607/calendardate",
3
3
  "private": false,
4
- "version": "0.1.0",
4
+ "version": "0.1.1",
5
5
  "type": "module",
6
6
  "main": "./src/index.ts",
7
7
  "types": "./src/index.ts",
@@ -9,6 +9,7 @@
9
9
  ".": "./src/index.ts"
10
10
  },
11
11
  "devDependencies": {
12
+ "typescript": "^5.7.2",
12
13
  "vitest": "^4.1.10"
13
14
  },
14
15
  "description": "Calendar dates without a timezone \u2014 a year, a month, a day, and the arithmetic that goes with them.",
@@ -35,5 +36,13 @@
35
36
  },
36
37
  "publishConfig": {
37
38
  "access": "public"
39
+ },
40
+ "repository": {
41
+ "type": "git",
42
+ "url": "git+https://github.com/dyadav4/calendardate.git"
43
+ },
44
+ "homepage": "https://github.com/dyadav4/calendardate#readme",
45
+ "bugs": {
46
+ "url": "https://github.com/dyadav4/calendardate/issues"
38
47
  }
39
48
  }
@@ -1,14 +1,13 @@
1
1
  /**
2
2
  * A calendar date with no time-of-day and no timezone.
3
3
  *
4
- * Release dates are calendar dates, not instants: an entry dated 2026-08-01 must
5
- * group as 2026-08-01 for every viewer regardless of their timezone. Representing
6
- * dates as year/month/day fields keeps them out of the JS `Date` type, where
7
- * parsing "2026-08-01" yields a UTC midnight instant that reads back as July 31
8
- * anywhere west of UTC.
4
+ * A birthday, a due date, a release date: these are calendar dates rather than
5
+ * instants. The 1st of August is the 1st of August wherever it is read, and
6
+ * anything dated that way must stay that way for every reader.
9
7
  *
10
- * Lives in `shared/` because nothing about it is film-specific: any feature
11
- * dealing in dates watchlists, reminders wants the same representation.
8
+ * Holding the fields separately keeps them out of the JS `Date` type, where
9
+ * parsing "2026-08-01" yields a UTC midnight instant that reads back as July 31
10
+ * anywhere west of UTC — the bug this exists to avoid.
12
11
  */
13
12
  export interface CalendarDate {
14
13
  /** Four-digit year. */