[
{
"path": ".agignore",
"content": "/build\npackage-lock.json\n"
},
{
"path": ".babelrc",
"content": "{\n \"presets\": [\n \"@babel/preset-env\"\n ]\n}\n"
},
{
"path": ".editorconfig",
"content": "root = true\n\n[*]\ncharset = utf-8\nindent_size = 2\nend_of_line = lf\nindent_style = space\ninsert_final_newline = false\ntrim_trailing_whitespace = true\n\n[*.md]\ntrim_trailing_whitespace = false\n"
},
{
"path": ".gitattributes",
"content": "scripts/* linguist-vendored\ndocker/* linguist-vendored\nsite/** linguist-vendored\n.husky/* linguist-vendored\n"
},
{
"path": ".github/ISSUE_TEMPLATE/bug_report.md",
"content": "---\nname: Bug report\nabout: Create a report to help us improve\ntitle: \"\"\nlabels: bug\n---\n\n**Describe the bug**\nA clear and concise description of what the bug is.\n\n**To Reproduce**\nPlease share a minimal code example that triggers the problem:\n\n**Actual vs Expected behavior**\nA clear and concise description of what you expected to happen.\n\n**Desktop (please complete the following information):**\n\n- OS: [e.g. iOS]\n- Browser [e.g. Chrome 84, safari 14.0]\n- Luxon version [e.g. 1.25.0]\n- Your timezone [e.g. \"America/New_York\"]\n\n**Additional context**\nAdd any other context about the problem here.\n"
},
{
"path": ".github/ISSUE_TEMPLATE/feature_request.md",
"content": "---\nname: Feature request\nabout: Suggest an idea for this project\ntitle: \"\"\nlabels: enhancement\n---\n\n**Is your feature request related to a problem? Please describe.**\nA clear and concise description of what the problem is. Ex. I'm always frustrated when [...]\n\n**Describe the solution you'd like**\nA clear and concise description of what you want to happen.\n\n**Describe alternatives you've considered**\nA clear and concise description of any alternative solutions or features you've considered.\n\n**Additional context**\nAdd any other context or screenshots about the feature request here.\n"
},
{
"path": ".github/workflows/test.yml",
"content": "name: Test\n\non:\n push:\n branches: [master]\n pull_request:\n branches: [master]\n\njobs:\n build-and-test:\n runs-on: ubuntu-latest\n\n env:\n LANG: en_US.utf8\n LIMIT_JEST: yes\n TZ: America/New_York\n\n strategy:\n matrix:\n node-version:\n - 18.20.8 # latest 18.x\n - 20.19.4 # latest 20.x\n - 22.17.1 # latest 22.x\n - 24.4.1 # latest 22.x\n\n steps:\n - uses: actions/checkout@v3\n - name: Use Node.js ${{ matrix.node-version }}\n uses: actions/setup-node@v3\n with:\n node-version: ${{ matrix.node-version }}\n cache: \"npm\"\n - run: npm ci\n - run: npm run build\n - run: npm run format-check\n - run: npm run test\n - run: npm run site\n - run: bash <(curl -s https://codecov.io/bash)"
},
{
"path": ".gitignore",
"content": "node_modules\n.tern-port\n/build\n#*\n.#*\ncoverage/\n.DS_Store\n.external-ecmascript.js\n.idea\n.vscode\ntest/scratch.test.js\n"
},
{
"path": ".husky/.gitignore",
"content": "_\n"
},
{
"path": ".husky/pre-commit",
"content": "#!/bin/sh\n. \"$(dirname \"$0\")/_/husky.sh\"\n\nnpx lint-staged\n"
},
{
"path": ".prettierrc",
"content": "{ \"printWidth\": 100 }\n"
},
{
"path": "CHANGELOG.md",
"content": "# Changelog\n\n# 3.7.2 (2025-07-09)\n- Fix ES6 packaging\n\n# 3.7.1 (2025-07-09)\n- Revert change in ES6 packaging\n\n# 3.7.0 (2025-07-09)\n- Added `showZeros` option to `Duration#toHuman`\n- Added `Duration#removeZeros` method.\n- Added `rounding` option to `DateTime#toRelative`\n- Added `precision` option to ISO formatting methods\n- Added `signMode` option to `Duration#toFormat`\n- Allow escaping single quotes in format strings\n- Improve output of `Info.months` and `Info.monthsFormat` for `ja` locale\n- Accept lowercase `t` as a separator in ISO strings\n- Accept lowercase `z` as an offset in ISO strings\n- Reject non-finite numbers where previously only `NaN` was rejected\n- Improve the documentation for Interval\n- Added a dark theme for the documentation site\n\n# 3.6.1 (2025-03-31)\n- Add Fallback for `minimalDays` being removed from Intl.WeekInfo\n- Fix various caches when JS keywords like \"constructor\" are used for names\n\n# 3.6.0 (2025-03-25)\n- Add `Interval.lastDateTime`\n- Fix a bug that could cause wrong timezone calculations when multiple timezones are in use \n\n# 3.5.0 (2024-08-03)\n\n- Various performance improvements\n- throwOnInvalid causes the constructor to throw if the year is invalid\n\n# 3.4.4 (2023-11-12)\n\n- Localized week support (#1454)\n- Added custom inspect for Node (#1526)\n- Fix sorting in `Interval.splitAt` (#1524)\n\n# 3.4.3 (2023-09-05)\n\n- Fixes another regression from 3.4.0 (#1496)\n\n# 3.4.2 (2023-08-26)\n\n- Fixes regression from 3.4.1 (#1493)\n\n# 3.4.1 (2023-08-23)\n\n- Fixes for regressions from 3.4.0 (#1482 and #1488)\n\n# 3.4.0 (2023-08-08)\n\n- Fix type checking on input zones\n- Fix Islamic months listing\n- Fix normalize() for negative inputs\n\n# 3.3.0 (2023-03-03)\n\n- Fix off-by-one in Interval#count (#1308)\n- Support formatting for custom zones (#1377)\n- Fix parsing for narrow spaces (#1369)\n- Handle leap year issue with AD 100 (#1390)\n- Allow parsing of just an offset\n\n# 3.2.1 (2023-01-04)\n\n- Fix for RFC-2822 regex vulnerability\n- Better handling of BCP tags with -x- extensions\n\n# 3.2.0 (2022-12-29)\n\n- Allow timeZone to be specified as an intl option\n- Fix for diff's handling of end-of-month when crossing leap years (#1340)\n- Add Interval.toLocaleString() (#1320)\n\n# 3.1.1 (2022-11-28)\n\n- Add Settings.twoDigitCutoffYear\n\n# 3.1.0 (2022-10-31)\n\n- Add Duration.rescale\n\n# 3.0.4 (2022-09-24)\n\n- Fix quarters in diffs (#1279)\n- Export package.json in package (#1239)\n\n# 3.0.2 (2022-08-28)\n\n- Lots of doc changes\n- Added DateTime.expandFormat\n- Added support for custom conversion matrices in Durations\n\n# 3.0.1 (2022-07-09)\n\n- Add DateTime.parseFormatForOpts\n\n# 3.0.0 (2022-07-09)\n\n- Add \"default\" as an option for specifying a zone, and change \"system\" to really mean the system zone (breaking change)\n\n# 2.5.0 (2022-07-09)\n\n- Support for ESM-style node imports\n- Fix Wednesday parsing for RFC 850 strings\n- Increase number of digits allowed in ISO durations\n\n## 2.4.0 (2022-05-08)\n\n- Add support for parsing the ISO zone extension, like `2022-05-08T20:42:00.000-04:00[America/New_York]`\n- Add an `extendedZone` option to `toISO()` and `toISOTime`\n- Improvements to `DateTime.isInDST()`\n- Fix for parsing in Vietnames (and probably other languages)\n\n## 2.3.2 (2022-04-17)\n\n- Fix timezone calculations for negative years\n- add week formatting token \"w\" for durations\n- fix weekday computation for years 0-100\n\n## 2.3.1 (2022-02-23)\n\n- Added an `includeOffsetSpace` option to `toSQL` and `toSQLTime`\n- Added `toUnixInteger`\n- Don't use `-0` when negating durations with zeros in them\n\n## 2.3.0 (2022-01-02)\n\n- Major perf improvements to `toISO()`, `toISODate()`, `toISOTime()`, and `toSQLDate()`\n- Fixed date padding for negative years in `toISO()`\n- Added Duration#toHuman()\n\n## 2.2.0 (2021-12-10)\n\n- Allow offsets to pick among ambiguous times when both an offset and zone are provided to `fromFormat`\n- Fix a floating point bug in `Duration.shiftTo()`\n\n## 2.1.1 (2021-11-08)\n\n- Fix issue in quirky environments that lack `hourCycle` support and sometimes computed offsets 12 hours off\n\n## 2.1.0 (2021-11-07)\n\n- Stop special casing of `Etc/GMT*` zones\n- export fromDurationLike\n- memoize zone validation\n- Support for fractional elements in duration ISO parsing\n- Added `uu` and `uuu` tokens for fractional millisecond parsing\n\n## 2.0.2 (2021-08-08)\n\nFix locale defaulting\n\n## 2.0.0 (2021-07-3)\n\nSee [Upgrading section](https://moment.github.io/luxon/#/upgrading?id=_1x-to-20)\n\n## 1.28.0 (2021-07-03)\n\n- Fix ISO parsing for offset specifiers in Year-Ordinal formats\n\n## 1.27.0 (2021-05-08)\n\n- Fix GMT zone parsing for older versions of Node\n- Support multiple units in `toRelative`\n- Various documentation updates\n\n## 1.26.0 (2021-02-13)\n\n- Add fromISOTime, toISOTime and toMillis to Duration (#803)\n- Fix padding of negative years in IsoDate (#871)\n- Fix hasSame unit comparison (#798)\n- Export VERSION information (#794)\n- Durations are considered equal with extra zero units. Fixes #809 (#811)\n\n## 1.25.0 (2020-08-23)\n\n- fix fromFormat with Intl formats containing non-breaking spaces\n- Support higher precision in ISO milliseconds\n- Some fixes for 00:30 timezones\n- Fix some throwOnInvalid for invalid Intervals\n- Various doc fixes\n- Fix Interval#isSame for empty intervals\n- Mark package as side effect-free\n- Add support for intervals with a large number of seconds\n\n## 1.24.1 (2020-05-04)\n\n- Remove erroneous `console.log` call\n\n## 1.24.0 (2020-05-03)\n\n- Update polyfills for pollyfilled build\n\n## 1.23.0 (2020-04-02)\n\n- Allow minus sign prefix when creating Duration from ISO\n\n## 1.22.2 (2020-03-25)\n\n- Added more details to error messages for type errors\n\n## 1.22.1 (2020-03-19)\n\n- Added support for ISO basic format to DateTime#toISO\n\n## 1.22.0 (2020-01-26)\n\n- Fix setZone's handling of pre-1970 dates with millisecond components\n- Fix keepLocalTime for large jumps near the target zone's DST\n- Fix cache perf for toRelative()\n\n## 1.21.3 (2019-11-28)\n\n- Fix parsing of meridiems in macro tokens in newer versions of v8\n\n## 1.21.2 (2019-11-18)\n\n- Fix bug in Chrome Canary that threw off time zone calculations\n\n## 1.21.1 (2019-11-03)\n\n- Fix for quarter parsing\n- Some documentation updates\n\n## 1.21.0 (2019-10-30)\n\n- Added quarter support to the parser\n- Fix some rounding issues in ISO formatting\n\n## 1.20.0 (2019-10-29)\n\n- Added Duration#mapUnits\n- added Interval#toISODate and Interval#toISOTime\n- Some documentation fixes\n\n## 1.19.3\n\n- Cache offset values\n- Fix handling of negative sub 1-hour offsets\n\n## 1.19.2\n\n- Speculative fix for Node 6\n\n## 1.19.1\n\n- Fix Intl.DateTimeFormat usage for polyfills\n\n## 1.19.0\n\n- Interval#splitAt now ignores input dates outside the interval\n- Don't allow decimals in DateTime creation\n\n## 1.18.2\n\n- Fix handling of decimals in DateTime#plus and #minus\n\n## 1.18.1\n\n- Fix validity when adding or subtracting time that exceeds Date max/min boundaries\n\n## 1.18.0\n\n- Add support for macro tokens in the parser\n\n## 1.17.2\n\n- Fix issue with `toRelative` using `style: short` with plural days\n\n## 1.17.1\n\n- Reject out-of-range numbers in DateTime.fromMillis\n- Reject 0s in ISO date inputs\n\n## 1.17.0\n\n- DateTime.min and DateTime.max throw if they get the wrong kind of arguments\n- Fixed throwOnInvalid logic for Interval\n- Added `DATETIME_MED_WITH_WEEKDAY` preset\n\n## 1.16.1\n\n- Catch errors trying to use Intl in weird versions of IE 11\n\n## 1.16.0\n\n- Fixed locale default logic for `DateTime#toFormat(\"ZZZZ\")\n\n## 1.15.0\n\n- Added `formatOffset` to Zones\n\n## 1.14.0\n\n- Allow the zone argument to Interval.fromISO with duration components\n- Ignore the zone argument to Duration factory methods\n\n## 1.13.3\n\n- Fix keepLocalTime calculations that span offset changes\n\n## 1.13.2\n\n- Fixed ISO formatting for dates > 999\n\n## 1.13.1\n\n- Performance improvements for regex parsing\n\n## 1.13.0\n\n- Support numberSystem in fromFormat\n- Fix validity for bad initial zone specifiers\n\n## 1.12.1\n\n- Fix cross-month diffs in some scenarios\n- Fix time zone parsing when the time zone isn't at the end\n- Memoize IANA zone creation\n\n## 1.12.0\n\n- Add some explicit CDN support to the NPM package\n- Add week token to duration ISO support\n- Lots of cleanup and test coverage changes\n\n## 1.11.4\n\n- `setZone(\"local\")` now returns the defaultZone if it is set\n- Fixes for the polyfilled build\n\n## 1.11.3\n\n- Allow 24:00 in ISO (and other) strings\n- Fix some bugs with the typecheck functions like `DateTime.isDateTime()`\n\n## 1.11.2\n\n- Fixed handling of some characters in fromFormat literal sections\n- Handle string values in object arguments to DateTime methods\n- Fixed toRelativeCalendar's handling of zones in the base date\n\n## 1.11.1\n\n- Fix DateTime#plus() when spanning across AD 100\n\n## 1.11.0\n\n- Fix low-year handling for IANA zones\n- `DateTime#toLocal()` now uses the default locale\n- Fix zero duration formatting\n- Many documentation fixes\n\n## 1.10.0\n\n- Fix endOf(\"day\") during DSTs (#399)\n- Add `Interval#mapEndpoints (#400)\n- Add `DateTime#zone` and `Info.normalizeZone` (#404)\n\n## 1.9.0\n\n- Add `DateTime#toRelative` and `DateTime#toRelativeCalendar`\n\n## 1.8.3\n\n- Allow \"UTC\" in the zone position of `fromSQL`\n- Force `isDateTime` and `isDuration` to return booleans in all cases\n\n## 1.8.2\n\n- Trim leading \\u200e characters from offset names in Edge 16 and 17\n\n## 1.8.1\n\n- Add `DateTime.fromSeconds` and `DateTime#toSeconds`\n\n## 1.7.1\n\n- Floor the seconds instead of rounding them when outputting the 'X' format\n- Change the options to toLocale to override the configuration (the previous options were essentially ignored)\n\n## 1.6.2\n\n- Fixing merge error that resulted in bad error messages\n\n## 1.6.0\n\n- **midly breaking** Rework negative durations\n- Fix handling\n"
},
{
"path": "CONTRIBUTING.md",
"content": "# Contributing to Luxon\n\n## General guidelines\n\nPatches are welcome. Luxon is at this point just a baby and it could use lots of help. But before you dive in...Luxon is one of those tightly-scoped libraries where the default answer to \"should this library do X?\" is likely \"no\". **So ask first!** It might save you some time and energy.\n\nHere are some vague notes on Luxon's design philosophy:\n\n1. We won't accept patches that can't be internationalized using the JS environment's (e.g. the browser's) native capabilities. This means that most convenient humanization features are out of scope.\n1. We try hard to have a clear definition of what Luxon does and doesn't do. With few exceptions, this is not a \"do what I mean\" library.\n1. Luxon shouldn't contain simple conveniences that bloat the library to save callers a couple lines of code. Write those lines in your own code.\n1. Most of the complexity of JS module loading compatibility is left to the build. If you have a \"this can't be loaded in my bespoke JS module loader\" problems, this isn't something you should be solving with changes to the `src` directory. If it's a common use case and is possible to generate with Rollup, it can get its own build command.\n1. We prefer documentation clarifications and gotchas to go in the docstrings, not in the guides on the docs page. Obviously, if the guides are wrong, they should be fixed, but we don't want them to turn into troubleshooting pages. On the other hand, making sure the method-level documentation has ample examples and notes is great.\n1. You'll need to sign a CLA as part of your first pull request to Luxon.\n\n## Building and testing\n\nBuilding and testing is done through npm scripts. The tests run in Node and require Node 18 with full-icu support. This is because some of the features available in Luxon (like internationalization and time zones) need that stuff and we test it all. On any platform, if you have Node 18 installed with full-icu, you're good to go; just run `scripts/test`. But you probably don't have that, so read on.\n\n### OSX\n\nMac is easy:\nOpen the terminal.\n\n```\nbrew install node --with-full-icu\nnpm install\n./scripts/test\n```\n\nIf that's for whatever reason a pain, the Linux instructions should also work, as well as the Docker ones.\n\n### Linux\n\nThere are two ways to get full-icu support in Linux: build it with that support, or provide it as a module. We'll cover the latter. Assuming you've installed Node 10:\n\n```\nnpm install\nnpm install full-icu\n./scripts/test\n```\n\nWhere `scripts/test` is just `NODE_ICU_DATA=\"$(pwd)/node_modules/full-icu\" npm run test`, which is required for making Node load the full-icu module you just installed. You can run all the other npm scripts (e.g. `npm run docs`) directly; they don't require Intl support.\n\n### Windows\n\nIf you have [Bash](https://git-scm.com/downloads) or [WSL](https://docs.microsoft.com/en-us/windows/wsl/install-win10), the Linux instructions seem to work fine.\n\nI would love to add instructions for a non-WSL install of the dev env!\n\n### Docker\n\nIn case messing with your Node environment just to run Luxon's tests is too much to ask, we've provided a Docker container. You'll need a functioning Docker environment, but the rest is easy:\n\n```\n./docker/npm install --ignore-scripts\n./docker/npm test\n```\n\n## Patch basics\n\nOnce you're sure your bugfix or feature makes sense for Luxon, make sure you take these steps:\n\n1. Be sure to add tests and run them with `scripts/test`\n1. Be sure you run `npm run format` before you commit. Note this will modify your source files to line up with the style guidelines.\n1. Make sure you add or ESDoc annotations appropriately. You can run `npm run docs` to generate the HTML for them. They land in the `build/docs` directory. This also builds the markdown files in `/docs` into the guide on the Luxon website.\n1. To test Luxon in your browser, run `npm run site` and then open `build/demo/global.html`. You can access Luxon classes in the console like `window.luxon.DateTime`.\n1. To test in Node, run `npm run build` and then run something like `var DateTime = require('./build/cjs-browser/luxon').DateTime`.\n\nLuxon uses [Husky](https://github.com/typicode/husky) to run the formatter on your code as a pre-commit hook. You should still run `npm run format` yourself to catch other issues, but this hook will help prevent you from failing the build with a trivial formatting error.\n\n## npm script reference\n\n| Command | Function |\n| ---------------------------- | --------------------------------------- |\n| `npm run build` | Build all the distributable files |\n| `npm run build-node` | Build just for Node |\n| `npm run test` | Run the test suite, but see notes above |\n| `npm run format` | Run the Prettier formatter |\n| `npm run site` | Build the Luxon website, including docs |\n| `npm run check-doc-coverage` | Check whether there's full doc coverage |\n| `npm run benchmark` | Run performance benchmarks |\n"
},
{
"path": "LICENSE.md",
"content": "Copyright 2019 JS Foundation and other contributors\n\nPermission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the \"Software\"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:\n\nThe above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.\n"
},
{
"path": "README.md",
"content": "# Luxon\n\n[![MIT License][license-image]][license] [![Build Status][github-action-image]][github-action-url] [![NPM version][npm-version-image]][npm-url] [![Coverage Status][test-coverage-image]][test-coverage-url] [![PRs welcome][contributing-image]][contributing-url]\n\nLuxon is a library for working with dates and times in JavaScript.\n\n```js\nDateTime.now().setZone(\"America/New_York\").minus({ weeks: 1 }).endOf(\"day\").toISO();\n```\n\n## 🚀 The road to Luxon 4.0\n\nPlease [read about and share your feedback](https://github.com/moment/luxon/discussions/1742) on the plans for the next major version of Luxon!\n\n## Upgrading to 3.0\n\n[Guide](https://moment.github.io/luxon/#upgrading)\n\n## Features\n * DateTime, Duration, and Interval types.\n * Immutable, chainable, unambiguous API.\n * Parsing and formatting for common and custom formats.\n * Native time zone and Intl support (no locale or tz files).\n\n## Download/install\n\n[Download/install instructions](https://moment.github.io/luxon/#/install)\n\n## Documentation\n\n* [General documentation](https://moment.github.io/luxon/#/?id=luxon)\n* [API docs](https://moment.github.io/luxon/api-docs/index.html)\n* [Quick tour](https://moment.github.io/luxon/#/tour)\n* [For Moment users](https://moment.github.io/luxon/#/moment)\n* [Why does Luxon exist?](https://moment.github.io/luxon/#/why)\n* [A quick demo](https://moment.github.io/luxon/demo/global.html)\n\n## Development\n\nSee [contributing](CONTRIBUTING.md).\n\n![Phasers to stun][phasers-image]\n\n[license-image]: https://img.shields.io/badge/license-MIT-blue.svg\n[license]: LICENSE.md\n\n[github-action-image]: https://github.com/moment/luxon/actions/workflows/test.yml/badge.svg\n[github-action-url]: https://github.com/moment/luxon/actions/workflows/test.yml\n\n[npm-url]: https://npmjs.org/package/luxon\n[npm-version-image]: https://badge.fury.io/js/luxon.svg\n\n[test-coverage-url]: https://codecov.io/gh/moment/luxon\n[test-coverage-image]: https://codecov.io/gh/moment/luxon/branch/master/graph/badge.svg\n\n[contributing-url]: https://github.com/moment/luxon/blob/master/CONTRIBUTING.md\n[contributing-image]: https://img.shields.io/badge/PRs-welcome-brightgreen.svg\n\n[phasers-image]: https://img.shields.io/badge/phasers-stun-brightgreen.svg\n"
},
{
"path": "babel.config.js",
"content": "module.exports = { presets: [\"@babel/preset-env\"] };\n"
},
{
"path": "benchmarks/datetime.js",
"content": "import Benchmark from \"benchmark\";\nimport DateTime from \"../src/datetime.js\";\nimport Settings from \"../src/settings.js\";\n\nfunction runDateTimeSuite() {\n return new Promise((resolve, reject) => {\n const suite = new Benchmark.Suite();\n\n const dt = DateTime.now();\n\n const formatParser = DateTime.buildFormatParser(\"yyyy/MM/dd HH:mm:ss.SSS\");\n\n suite\n .add(\"DateTime.now\", () => {\n DateTime.now();\n })\n .add(\"DateTime.fromObject with locale\", () => {\n DateTime.fromObject({}, { locale: \"fr\" });\n })\n .add(\"DateTime.local with numbers\", () => {\n DateTime.local(2017, 5, 15);\n })\n .add(\"DateTime.local with numbers and zone\", () => {\n DateTime.local(2017, 5, 15, 11, 7, 35, { zone: \"America/New_York\" });\n })\n .add(\"DateTime.fromISO\", () => {\n DateTime.fromISO(\"1982-05-25T09:10:11.445Z\");\n })\n .add(\"DateTime.fromSQL\", () => {\n DateTime.fromSQL(\"2016-05-14 10:23:54.2346\");\n })\n .add(\"DateTime.fromFormat\", () => {\n DateTime.fromFormat(\"1982/05/25 09:10:11.445\", \"yyyy/MM/dd HH:mm:ss.SSS\");\n })\n .add(\"DateTime.fromFormat with zone\", () => {\n DateTime.fromFormat(\"1982/05/25 09:10:11.445\", \"yyyy/MM/dd HH:mm:ss.SSS\", {\n zone: \"America/Los_Angeles\",\n });\n })\n .add(\"DateTime.fromFormatParser\", () => {\n DateTime.fromFormatParser(\"1982/05/25 09:10:11.445\", formatParser);\n })\n .add(\"DateTime.fromFormatParser with zone\", () => {\n DateTime.fromFormatParser(\"1982/05/25 09:10:11.445\", formatParser, {\n zone: \"America/Los_Angeles\",\n });\n })\n .add(\"DateTime#setZone\", () => {\n dt.setZone(\"America/Los_Angeles\");\n })\n .add(\"DateTime#toFormat\", () => {\n dt.toFormat(\"yyyy-MM-dd\");\n })\n .add(\"DateTime#toFormat with macro\", () => {\n dt.toFormat(\"T\");\n })\n .add(\"DateTime#toFormat with macro no cache\", () => {\n dt.toFormat(\"T\");\n Settings.resetCaches();\n })\n .add(\"DateTime#format in german\", () => {\n dt.setLocale(\"de-De\").toFormat(\"d. LLL. HH:mm\");\n })\n .add(\"DateTime#format in german and no-cache\", () => {\n dt.setLocale(\"de-De\").toFormat(\"d. LLL. HH:mm\");\n Settings.resetCaches();\n })\n .add(\"DateTime#add\", () => {\n dt.plus({ milliseconds: 3434 });\n })\n .add(\"DateTime#toISO\", () => {\n dt.toISO();\n })\n .add(\"DateTime#toLocaleString\", () => {\n dt.toLocaleString();\n })\n .add(\"DateTime#toLocaleString in utc\", () => {\n dt.toUTC().toLocaleString();\n })\n .add(\"DateTime#toRelativeCalendar\", () => {\n dt.toRelativeCalendar({ base: DateTime.now(), locale: \"fi\" });\n })\n .on(\"cycle\", (event) => {\n console.log(String(event.target));\n })\n .on(\"complete\", function () {\n console.log(\"Fastest is \" + this.filter(\"fastest\").map(\"name\"));\n resolve();\n })\n .on(\"error\", function () {\n reject(this.error);\n })\n .run();\n });\n}\n\nconst allSuites = [runDateTimeSuite];\n\nexport default allSuites;\n"
},
{
"path": "benchmarks/index.js",
"content": "import dateTimeSuites from \"./datetime.js\";\nimport infoSuites from \"./info.js\";\n\nconst allSuites = [...dateTimeSuites, ...infoSuites];\n\nasync function runAllSuites() {\n for (const runSuite of allSuites) {\n await runSuite();\n }\n}\n\nrunAllSuites();\n"
},
{
"path": "benchmarks/info.js",
"content": "import Benchmark from \"benchmark\";\nimport Info from \"../src/info.js\";\nimport Locale from \"../src/impl/locale.js\";\n\nfunction runWeekdaysSuite() {\n return new Promise((resolve, reject) => {\n const locale = Locale.create(null, null, null);\n\n new Benchmark.Suite()\n .add(\"Info.weekdays with existing locale\", () => {\n Info.weekdays(\"long\", { locObj: locale });\n })\n .add(\"Info.weekdays\", () => {\n Info.weekdays(\"long\");\n })\n .on(\"cycle\", (event) => {\n console.log(String(event.target));\n })\n .on(\"complete\", function () {\n console.log(\"Fastest is \" + this.filter(\"fastest\").map(\"name\"));\n resolve();\n })\n .on(\"error\", function () {\n reject(this.error);\n })\n .run();\n });\n}\n\nfunction runWeekdaysFormatSuite() {\n return new Promise((resolve, reject) => {\n const locale = Locale.create(null, null, null);\n\n new Benchmark.Suite()\n .add(\"Info.weekdaysFormat with existing locale\", () => {\n Info.weekdaysFormat(\"long\", { locObj: locale });\n })\n .add(\"Info.weekdaysFormat\", () => {\n Info.weekdaysFormat(\"long\");\n })\n .on(\"cycle\", (event) => {\n console.log(String(event.target));\n })\n .on(\"complete\", function () {\n console.log(\"Fastest is \" + this.filter(\"fastest\").map(\"name\"));\n resolve();\n })\n .on(\"error\", function () {\n reject(this.error);\n })\n .run();\n });\n}\n\nfunction runMonthsSuite() {\n return new Promise((resolve, reject) => {\n const locale = Locale.create(null, null, null);\n new Benchmark.Suite()\n .add(\"Info.months with existing locale\", () => {\n Info.months(\"long\", { locObj: locale });\n })\n .add(\"Info.months\", () => {\n Info.months(\"long\");\n })\n .on(\"cycle\", (event) => {\n console.log(String(event.target));\n })\n .on(\"complete\", function () {\n console.log(\"Fastest is \" + this.filter(\"fastest\").map(\"name\"));\n resolve();\n })\n .on(\"error\", function () {\n reject(this.error);\n })\n .run();\n });\n}\n\nfunction runMonthsFormatSuite() {\n return new Promise((resolve, reject) => {\n const locale = Locale.create(null, null, null);\n\n new Benchmark.Suite()\n .add(\"Info.monthsFormat with existing locale\", () => {\n Info.monthsFormat(\"long\", { locObj: locale });\n })\n .add(\"Info.monthsFormat\", () => {\n Info.monthsFormat(\"long\");\n })\n .on(\"cycle\", (event) => {\n console.log(String(event.target));\n })\n .on(\"complete\", function () {\n console.log(\"Fastest is \" + this.filter(\"fastest\").map(\"name\"));\n resolve();\n })\n .on(\"error\", function () {\n reject(this.error);\n })\n .run();\n });\n}\n\nconst allSuites = [runMonthsSuite, runMonthsFormatSuite, runWeekdaysSuite, runWeekdaysFormatSuite];\n\nexport default allSuites;\n"
},
{
"path": "benchmarks/package.json",
"content": "{\n \"type\": \"module\"\n}\n"
},
{
"path": "codecov.yml",
"content": "comment: false\ncoverage:\n status:\n project:\n default:\n target: auto\n threshold: null\n base: auto\n"
},
{
"path": "docker/Dockerfile",
"content": "FROM library/node:15-slim\n\nENV HUSKY_SKIP_INSTALL=1\n\nENV LANG=en_US.utf8\nENV LIMIT_JEST=yes\nENV CI=yes\nENV TZ=America/New_York\n"
},
{
"path": "docker/build",
"content": "#!/usr/bin/env bash\ndocker build docker -t icambron/luxon\n"
},
{
"path": "docker/npm",
"content": "#!/usr/bin/env bash\ndocker run -it --rm -v $(pwd):/luxon -w /luxon icambron/luxon npm $@\n"
},
{
"path": "docker/push",
"content": "#!/usr/bin/env bash\ndocker push icambron/luxon\n"
},
{
"path": "docker/readme.md",
"content": "Luxon provides a Docker container and some wrapping scripts to make it easier to run the tests.\n\n 1. The Dockerfile is really just here as an FYI. You shouldn't need to interact with it\n 1. `npm` is a bash script that runs `npm run [arg]` inside the Docker container.\n"
},
{
"path": "docs/calendars.md",
"content": "# Calendars\n\nThis covers Luxon's support for various calendar systems. If you don't need to use non-standard calendars, you don't need to read any of this.\n\n## Fully supported calendars\n\nLuxon has full support for Gregorian and ISO Week calendars. What I mean by that is that Luxon can parse dates specified in those calendars, format dates into strings using those calendars, and transform dates using the units of those calendars. For example, here is Luxon working directly with an ISO calendar:\n\n```js\nDateTime.fromISO('2017-W23-3').plus({ weeks: 1, days: 2 }).toISOWeekDate(); //=> '2017-W24-5'\n```\n\nThe main reason I bring all this is up is to contrast it with the capabilities for other calendars described below.\n\n## Output calendars\n\nLuxon has limited support for other calendaring systems. Which calendars are supported at all is a platform-dependent, but can generally be expected to be these: Buddhist, Chinese, Coptic, Ethioaa, Ethiopic, Hebrew, Indian, Islamic, Islamicc, Japanese, Persian, and ROC. **Support is limited to formatting strings with them**, hence the qualified name \"output calendar\".\n\nIn practice this is pretty useful; you can show users the date in their preferred calendaring system while the software works with dates using Gregorian units or Epoch milliseconds. But the limitations are real enough; Luxon doesn't know how to do things like \"add one Islamic month\".\n\nThe output calendar is a property of the DateTime itself. For example:\n\n```js\nvar dtHebrew = DateTime.now().reconfigure({ outputCalendar: \"hebrew\" });\ndtHebrew.outputCalendar; //=> 'hebrew'\ndtHebrew.toLocaleString() //=> '4 Tishri 5778'\n```\n\nYou can modulate the structure of that string with arguments to `toLocaleString` (see [the docs on that](formatting.md?id=tolocalestring-strings-for-humans)), but the point here is just that you got the alternative calendar.\n\n### Generally supported calendars\n\nHere's a table of the different calendars with examples generated formatting the same date generated like this:\n\n```js\nDateTime.fromObject({ outputCalendar: c }).toLocaleString(DateTime.DATE_FULL);\n```\n\nSince Luxon uses the browser's **Intl API**, you can use all the supported calendars.\n(See [Intl.Locale.prototype.getCalendars()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/Locale/getCalendars) for a full list)\n\n| Calendar | Example |\n| ------------------ | ------------------------ |\n| buddhist | September 24, 2560 BE |\n| chinese | Eighth Month 5, 2017 |\n| coptic | Tout 14, 1734 ERA1 |\n| ethioaa | Meskerem 14, 7510 ERA0 |\n| ethiopic | Meskerem 14, 2010 ERA1 |\n| hebrew | 4 Tishri 5778 |\n| indian | Asvina 2, 1939 Saka |\n| islamic | Muharram 4, 1439 AH |\n| islamic-civil | Muharram 3, 1439 AH |\n| islamic-umalqura | Muharram 3, 1439 AH |\n| iso8601 | September 24, 2017 |\n| japanese | September 24, 29 Heisei |\n| persian | Mehr 2, 1396 AP |\n| roc | September 24, 106 Minguo |\n\n\n\n### Default output calendar\n\nYou can set the default output calendar for new DateTime instances like this:\n\n```js\nSettings.defaultOutputCalendar = 'persian';\n```\n"
},
{
"path": "docs/formatting.md",
"content": "# Formatting\n\nThis section covers creating strings to represent a DateTime. There are three types of formatting capabilities:\n\n1. Technical formats like ISO 8601 and RFC 2822\n2. Internationalizable human-readable formats\n3. Token-based formatting\n\n## Technical formats (strings for computers)\n\n### ISO 8601\n\n[ISO 8601](https://en.wikipedia.org/wiki/ISO_8601) is the most widely used set of string formats for dates and times. Luxon can _parse_ a wide range of them, but provides direct support for formatting only a few of them:\n\n```js\ndt.toISO(); //=> '2017-04-20T11:32:00.000-04:00'\ndt.toISODate(); //=> '2017-04-20'\ndt.toISOWeekDate(); //=> '2017-W17-7'\ndt.toISOTime(); //=> '11:32:00.000-04:00'\n```\n\nGenerally, you'll want the first one. Use it by default when building or interacting with APIs, communicating times over a wire, etc.\n\n### HTTP and RFC 2822\n\nThere are a number of legacy standard date and time formats out there, and Luxon supports some of them. You shouldn't use them unless you have a specific reason to.\n\n```js\ndt.toRFC2822(); //=> 'Thu, 20 Apr 2017 11:32:00 -0400'\ndt.toHTTP(); //=> 'Thu, 20 Apr 2017 03:32:00 GMT'\n```\n\n### Unix timestamps\n\nDateTime objects can also be converted to numerical [Unix timestamps](https://en.wikipedia.org/wiki/Unix_time):\n\n```js\ndt.toMillis(); //=> 1492702320000\ndt.toSeconds(); //=> 1492702320.000\ndt.toUnixInteger(); // => 1492702320\ndt.valueOf(); //=> 1492702320000, same as .toMillis()\n```\n\n## toLocaleString (strings for humans)\n\n### The basics\n\nModern browsers (and other JS environments) provide support for human-readable, internationalized strings. Luxon provides convenient support for them, and you should use them anytime you want to display a time to a user. Use `toLocaleString` to do it:\n\n```js\ndt.toLocaleString(); //=> '4/20/2017'\ndt.toLocaleString(DateTime.DATETIME_FULL); //=> 'April 20, 2017 at 11:32 AM EDT'\ndt.setLocale('fr').toLocaleString(DateTime.DATETIME_FULL); //=> '20 avril 2017 à 11:32 UTC−4'\n```\n\n### Intl.DateTimeFormat\n\nIn the example above, `DateTime.DATETIME_FULL` is one of several convenience formats provided by Luxon. But the arguments are really any object of options that can be provided to [Intl.DateTimeFormat](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat). For example:\n\n```js\ndt.toLocaleString({ month: 'long', day: 'numeric' }); //=> 'April 20'\n```\n\nAnd that's all the preset is:\n\n```\nDateTime.DATETIME_FULL; //=> {\n // year: 'numeric',\n // month: 'long',\n // day: 'numeric',\n // hour: 'numeric',\n // minute: '2-digit',\n // timeZoneName: 'short'\n // }\n```\n\nThis also means you can modify the presets as you choose:\n\n```js\ndt.toLocaleString(DateTime.DATE_SHORT); //=> '4/20/2017'\nvar newFormat = {...DateTime.DATE_SHORT, weekday: 'long' };\ndt.toLocaleString(newFormat); //=> 'Thursday, 4/20/2017'\n```\n\n### Presets\n\nHere's the full set of provided presets using the October 14, 1983 at `13:30:23` as an example.\n\n| Name | Description | Example in en_US | Example in fr |\n| ---------------------------- | ------------------------------------------------------------------ | -------------------------------------------------------------- | ---------------------------------------------------------- |\n| `DATE_SHORT` | short date | `10/14/1983` | `14/10/1983` |\n| `DATE_MED` | abbreviated date | `Oct 14, 1983` | `14 oct. 1983` |\n| `DATE_MED_WITH_WEEKDAY` | abbreviated date with abbreviated weekday | `Fri, Oct 14, 1983` | `ven. 14 oct. 1983` |\n| `DATE_FULL` | full date | `October 14, 1983` | `14 octobre 1983` |\n| `DATE_HUGE` | full date with weekday | `Friday, October 14, 1983` | `vendredi 14 octobre 1983` |\n| `TIME_SIMPLE` | time | `1:30 PM` | `13:30` |\n| `TIME_WITH_SECONDS` | time with seconds | `1:30:23 PM` | `13:30:23` |\n| `TIME_WITH_SHORT_OFFSET` | time with seconds and abbreviated named offset | `1:30:23 PM EDT` | `13:30:23 UTC−4` |\n| `TIME_WITH_LONG_OFFSET` | time with seconds and full named offset | `1:30:23 PM Eastern Daylight Time` | `13:30:23 heure d’été de l’Est` |\n| `TIME_24_SIMPLE` | 24-hour time | `13:30` | `13:30` |\n| `TIME_24_WITH_SECONDS` | 24-hour time with seconds | `13:30:23` | `13:30:23` |\n| `TIME_24_WITH_SHORT_OFFSET` | 24-hour time with seconds and abbreviated named offset | `13:30:23 EDT` | `13:30:23 UTC−4` |\n| `TIME_24_WITH_LONG_OFFSET` | 24-hour time with seconds and full named offset | `13:30:23 Eastern Daylight Time` | `13:30:23 heure d’été de l’Est` |\n| `DATETIME_SHORT` | short date & time | `10/14/1983, 1:30 PM` | `14/10/1983 à 13:30` |\n| `DATETIME_MED` | abbreviated date & time | `Oct 14, 1983, 1:30 PM` | `14 oct. 1983 à 13:30` |\n| `DATETIME_MED_WITH_WEEKDAY` | abbreviated date & time with abbreviated weekday | `Fri, Oct 14, 1983, 1:30 PM` | `ven. 14 oct. 1983 à 13:30` |\n| `DATETIME_FULL` | full date and time with abbreviated named offset | `October 14, 1983 at 1:30 PM EDT` | `14 octobre 1983 à 13:30 UTC−4` |\n| `DATETIME_HUGE` | full date and time with weekday and full named offset | `Friday, October 14, 1983 at 1:30 PM Eastern Daylight Time` | `vendredi 14 octobre 1983 à 13:30 heure d’été de l’Est` |\n| `DATETIME_SHORT_WITH_SECONDS`| short date & time with seconds | `10/14/1983, 1:30:23 PM` | `14/10/1983 à 13:30:23` |\n| `DATETIME_MED_WITH_SECONDS` | abbreviated date & time with seconds | `Oct 14, 1983, 1:30:23 PM` | `14 oct. 1983 à 13:30:23` |\n| `DATETIME_FULL_WITH_SECONDS` | full date and time with abbreviated named offset with seconds | `October 14, 1983 at 1:30:23 PM EDT` | `14 octobre 1983 à 13:30:23 UTC−4` |\n| `DATETIME_HUGE_WITH_SECONDS` | full date and time with weekday and full named offset with seconds | `Friday, October 14, 1983 at 1:30:23 PM Eastern Daylight Time` | `vendredi 14 octobre 1983 à 13:30:23 heure d’été de l’Est` |\n\n### Intl\n\n`toLocaleString`'s behavior is affected by the DateTime's `locale`, `numberingSystem`, and `outputCalendar` properties. See the [Intl](intl.md) section for more.\n\n## Formatting with tokens (strings for Cthulhu)\n\nThis section covers generating strings from DateTimes with programmer-specified formats.\n\n### Consider alternatives\n\nYou shouldn't create ad-hoc string formats if you can avoid it. If you intend for a computer to read the string, prefer ISO 8601. If a human will read it, prefer `toLocaleString`. Both are covered above. However, if you have some esoteric need where you need some specific format (e.g. because some other software expects it), then `toFormat` is how you do it.\n\n### toFormat\n\nSee `DateTime#toFormat` for the API signature. As a brief motivating example:\n\n```js\nDateTime.fromISO('2014-08-06T13:07:04.054').toFormat('yyyy LLL dd'); //=> '2014 Aug 06'\n```\n\nThe supported tokens are described in the table below.\n\n### Intl\n\nAll of the strings (e.g. month names and weekday names) are internationalized by introspecting strings generated by the Intl API. Thus the exact strings you get are implementation-specific.\n\n```js\nDateTime.fromISO('2014-08-06T13:07:04.054')\n .setLocale('fr')\n .toFormat('yyyy LLL dd'); //=> '2014 août 06'\n```\n\nNote `toFormat` defaults to `en-US`. If you need the string to be internationalized, you need to set the locale explicitly like in the example above (or more preferably, use `toLocaleString`).\n\n### Escaping\n\nYou may escape strings using single quotes:\n\n```js\nDateTime.now().toFormat(\"HH 'hours and' mm 'minutes'\"); //=> '20 hours and 55 minutes'\n```\n\nSingle quotes themselves can be escaped by doubling them:\n```js\nDateTime.now().toFormat(\"MMM d ''yy\"); //=> Apr 7 '25\n```\n\n### Standalone vs format tokens\n\nSome tokens have a \"standalone\" and \"format\" version. Some languages require different forms of a word based on whether it is part of a longer phrase or just by itself (e.g. \"Monday the 22nd\" vs \"Monday\"). Use them accordingly.\n\n```js\nvar d = DateTime.fromISO('2014-08-06T13:07:04.054').setLocale('ru');\nd.toFormat('LLLL'); //=> 'август' (standalone)\nd.toFormat('MMMM'); //=> 'августа' (format)\n```\n\n### Macro tokens\n\nSome of the formats are \"macros\", meaning they correspond to multiple components. These use the native Intl API and will order their constituent parts in a locale-friendly way.\n\n```js\nDateTime.fromISO('2014-08-06T13:07:04.054').toFormat('ff'); //=> 'Aug 6, 2014, 1:07 PM'\n```\n\nThe macro options available correspond one-to-one with the preset formats defined for `toLocaleString`.\n\n### Table of tokens\n\n(Examples below given for `2014-08-06T13:07:04.054` considered as a local time in America/New_York).\n\n| Standalone token | Format token | Description | Example |\n|------------------| ------------ |----------------------------------------------------------------| ------------------------------------------------------------- |\n| S | | millisecond, no padding | `54` |\n| SSS | | millisecond, padded to 3 | `054` |\n| u | | fractional seconds, functionally identical to SSS | `054` |\n| uu | | fractional seconds, between 0 and 99, padded to 2 | `05` |\n| uuu | | fractional seconds, between 0 and 9 | `0` |\n| s | | second, no padding | `4` |\n| ss | | second, padded to 2 padding | `04` |\n| m | | minute, no padding | `7` |\n| mm | | minute, padded to 2 | `07` |\n| h | | hour in 12-hour time, no padding | `1` |\n| hh | | hour in 12-hour time, padded to 2 | `01` |\n| H | | hour in 24-hour time, no padding | `9` |\n| HH | | hour in 24-hour time, padded to 2 | `13` |\n| Z | | narrow offset | `+5` |\n| ZZ | | short offset | `+05:00` |\n| ZZZ | | techie offset | `+0500` |\n| ZZZZ | | abbreviated named offset | `EST` |\n| ZZZZZ | | unabbreviated named offset | `Eastern Standard Time` |\n| z | | IANA zone | `America/New_York` |\n| a | | meridiem | `AM` |\n| d | | day of the month, no padding | `6` |\n| dd | | day of the month, padded to 2 | `06` |\n| c | E | day of the week, as number from 1-7 (Monday is 1, Sunday is 7) | `3` |\n| ccc | EEE | day of the week, as an abbreviate localized string | `Wed` |\n| cccc | EEEE | day of the week, as an unabbreviated localized string | `Wednesday` |\n| ccccc | EEEEE | day of the week, as a single localized letter | `W` |\n| L | M | month as an unpadded number | `8` |\n| LL | MM | month as a padded number | `08` |\n| LLL | MMM | month as an abbreviated localized string | `Aug` |\n| LLLL | MMMM | month as an unabbreviated localized string | `August` |\n| LLLLL | MMMMM | month as a single localized letter | `A` |\n| y | | year, unpadded | `2014` |\n| yy | | two-digit year | `14` |\n| yyyy | | four- to six- digit year, pads to 4 | `2014` |\n| G | | abbreviated localized era | `AD` |\n| GG | | unabbreviated localized era | `Anno Domini` |\n| GGGGG | | one-letter localized era | `A` |\n| kk | | ISO week year, unpadded | `14` |\n| kkkk | | ISO week year, padded to 4 | `2014` |\n| W | | ISO week number, unpadded | `32` |\n| WW | | ISO week number, padded to 2 | `32` |\n| ii | | Local week year, unpadded | `14` |\n| iiii | | Local week year, padded to 4 | `2014` |\n| n | | Local week number, unpadded | `32` |\n| nn | | Local week number, padded to 2 | `32` |\n| o | | ordinal (day of year), unpadded | `218` |\n| ooo | | ordinal (day of year), padded to 3 | `218` |\n| q | | quarter, no padding | `3` |\n| qq | | quarter, padded to 2 | `03` |\n| D | | localized numeric date | `9/4/2017` |\n| DD | | localized date with abbreviated month | `Aug 6, 2014` |\n| DDD | | localized date with full month | `August 6, 2014` |\n| DDDD | | localized date with full month and weekday | `Wednesday, August 6, 2014` |\n| t | | localized time | `9:07 AM` |\n| tt | | localized time with seconds | `1:07:04 PM` |\n| ttt | | localized time with seconds and abbreviated offset | `1:07:04 PM EDT` |\n| tttt | | localized time with seconds and full offset | `1:07:04 PM Eastern Daylight Time` |\n| T | | localized 24-hour time | `13:07` |\n| TT | | localized 24-hour time with seconds | `13:07:04` |\n| TTT | | localized 24-hour time with seconds and abbreviated offset | `13:07:04 EDT` |\n| TTTT | | localized 24-hour time with seconds and full offset | `13:07:04 Eastern Daylight Time` |\n| f | | short localized date and time | `8/6/2014, 1:07 PM` |\n| ff | | less short localized date and time | `Aug 6, 2014, 1:07 PM` |\n| fff | | verbose localized date and time | `August 6, 2014, 1:07 PM EDT` |\n| ffff | | extra verbose localized date and time | `Wednesday, August 6, 2014, 1:07 PM Eastern Daylight Time` |\n| F | | short localized date and time with seconds | `8/6/2014, 1:07:04 PM` |\n| FF | | less short localized date and time with seconds | `Aug 6, 2014, 1:07:04 PM` |\n| FFF | | verbose localized date and time with seconds | `August 6, 2014, 1:07:04 PM EDT` |\n| FFFF | | extra verbose localized date and time with seconds | `Wednesday, August 6, 2014, 1:07:04 PM Eastern Daylight Time` |\n| X | | unix timestamp in seconds | `1407287224` |\n| x | | unix timestamp in milliseconds | `1407287224054` |\n"
},
{
"path": "docs/home.md",
"content": "## Luxon\n\nLuxon is a library for dealing with dates and times in JavaScript.\n\n```js\nDateTime.now().setZone('America/New_York').minus({weeks:1}).endOf('day').toISO();\n```\n\n### Features\n\n * A nice API for working with datetimes\n * Interval support (from time x to time y)\n * Duration support (14 days, 5 minutes, 33 seconds)\n * [Parsing](parsing.md) and [Formatting](formatting.md) datetimes, intervals, and durations\n * [Internationalization](intl.md) of strings using the Intl API\n * Detailed and unambiguous [math](math.md) operations\n * Built-in handling of [time zones](zones.md)\n * Partial support for multiple [calendar systems](calendars.md)\n \n For more, see the docs on the left, including the [api docs](api-docs/index.html ':ignore')\n \n### Getting started\n \n * [Demo](https://moment.github.io/luxon/demo/global.html ':ignore')\n * Read the [quick tour](tour.md)\n * Browse the topic docs on the left\n * Read the [api docs](api-docs/index.html ':ignore')\n\nLogo by [John Dalziel](https://github.com/crashposition)\n"
},
{
"path": "docs/install.md",
"content": "# Install guide\n\nLuxon provides different builds for different JS environments. See below for a link to the right one and instructions on how to use it. Luxon supports all modern platforms, but see [the support matrix](matrix.md) for additional details.\n\n## Basic browser setup\n\n- [Download full](https://moment.github.io/luxon/global/luxon.js)\n- [Download minified](https://moment.github.io/luxon/global/luxon.min.js)\n\nYou can also load the files from a [CDN](https://www.jsdelivr.com/package/npm/luxon).\n\nJust include Luxon in a script tag. You can access its various classes through the `luxon` global.\n\n```html\n\n```\n\nYou may wish to alias the classes you use:\n\n```js\nvar DateTime = luxon.DateTime;\n```\n\n## Node.js\n\nSupports Node.js 6+. Install via NPM:\n\n```\nnpm install --save luxon\n```\n\n```js\nconst { DateTime } = require(\"luxon\");\n```\n\nIf you want to work with locales, you need ICU support:\n\n 1. **For Node.js 13+, it comes built-in, no action necessary**\n 2. For older versions of Node.js (only 12 is supported), you need to install it yourself:\n 1. Install a build of Node.js with full ICU baked in, such as via nvm: nvm install -s --with-intl=full-icu --download=all or brew: brew install node --with-full-icu\n 2. Install the ICU data externally and point Node.js to it. The instructions on how to do that are below.\n\nThe instructions for using full-icu as a package are a little confusing. Node.js can't automatically discover that you've installed it, so you need to tell it where to find the data, like this:\n\n```\nnpm install full-icu\nnode --icu-data-dir=./node_modules/full-icu\n```\n\nYou can also point to the data with an environment var, like this:\n\n```\nNODE_ICU_DATA=\"$(pwd)/node_modules/full-icu\" node\n```\n\n## AMD (System.js, RequireJS, etc)\n\n- [Download full](https://moment.github.io/luxon/amd/luxon.js)\n- [Download minified](https://moment.github.io/luxon/amd/luxon.min.js)\n\n```js\nrequirejs([\"luxon\"], function(luxon) {\n //...\n});\n```\n\n## ES6\n\n- [Download full](https://moment.github.io/luxon/es6/luxon.js)\n- [Download minified](https://moment.github.io/luxon/es6/luxon.min.js)\n\n```js\nimport { DateTime } from \"luxon\";\n```\n\n## Webpack\n\n```\nnpm install --save luxon\n```\n\n```js\nimport { DateTime } from \"luxon\";\n```\n\n## Types\n\nThere are third-party typing files for Flow (via [flow-typed](https://github.com/flowtype/flow-typed)) and TypeScript (via [DefinitelyTyped](https://github.com/DefinitelyTyped/DefinitelyTyped)).\n\nFor Flow, use:\n\n```\nflow-typed install luxon\n```\n\nFor TypeScript, use:\n\n```\nnpm install --save-dev @types/luxon\n```\n\n## React Native\n\nReact Native >=0.70 works just fine out of the box. Older versions of React Native for Android (or if you disable Hermes) doesn't include Intl support by default, which you need for [a lot of Luxon's functionality](matrix.md).\n\nFor React Native >=0.60, you should configure the build flavor of jsc in `android/app/build.gradle`:\n\n```diff\n-def jscFlavor = 'org.webkit:android-jsc:+'\n+def jscFlavor = 'org.webkit:android-jsc-intl:+'\n```\n\nFor even older versions of React Native you can use [jsc-android-buildscripts](https://github.com/SoftwareMansion/jsc-android-buildscripts) to fix it.\n"
},
{
"path": "docs/intl.md",
"content": "# Intl\n\nLuxon uses the native Intl API to provide easy-to-use internationalization. A quick example:\n\n```js\nDateTime.now()\n .setLocale(\"el\")\n .toLocaleString(DateTime.DATE_FULL); //=> '24 Σεπτεμβρίου 2017'\n```\n\n## Making sure you have access to other locales\n\nPlease see the [install guide](install.md) for instructions on making sure your platform has access to the Intl APIs and the ICU data to power it. This especially important for Node, which doesn't ship with ICU data by default.\n\n## How locales work\n\nLuxon DateTimes can be configured using [BCP 47](https://tools.ietf.org/html/rfc5646) locale strings specifying the language to use generating or interpreting strings. The native Intl API provides the actual internationalized strings; Luxon just wraps it with a nice layer of convenience and integrates the localization functionality into the rest of Luxon. The Mozilla MDN Intl docs have a [good description](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl#Locale_identification_and_negotiation) of how the `locale` argument works. In Luxon, the methods are different but the semantics are the same, except in that Luxon allows you to specify a numbering system and output calendar independently of the locale string.\n\nThe rest of this document will concentrate on what Luxon does when provided with locale information.\n\n## Setting the locale\n\n`locale` is a property of Luxon object. Thus, locale is a sort of setting on the DateTime object, as opposed to an argument you provide the different methods that need internationalized.\n\nYou can generally set it at construction time:\n\n```js\nvar dt = DateTime.fromISO(\"2017-09-24\", { locale: \"fr\" });\ndt.locale; //=> 'fr'\n```\n\nIn this case, the specified locale didn't change the how the parsing worked (there's nothing localized about it), but it did set the locale property in the resulting instance. For other factory methods, such as `fromFormat`, the locale argument _does_ affect how the string is parsed. See further down for more.\n\nYou can change the locale of a DateTime instance (meaning, create a clone DateTime with a different locale) using `setLocale`:\n\n```js\nDateTime.now().setLocale(\"fr\").locale; //=> 'fr'\n```\n\n`setLocale` is just a convenience for `reconfigure`:\n\n```js\nDateTime.now().reconfigure({ locale: \"fr\" }).locale; //=> 'fr'\n```\n\n## Default locale\n\n### Out-of-the-box behavior\n\nBy default, the `locale` property of a new DateTime or Duration is the system locale. On a browser, that means whatever the user has their browser or OS language set to. On Node, that usually means en-US.\n\nAs a result, `DateTime#toLocaleString`, `DateTime#toLocaleParts`, and other human-readable-string methods like `Info.months` will by default generate strings in the user's locale.\n\nHowever, note that `DateTime.fromFormat` and `DateTime#toFormat` fall back on en-US. That's because these methods are often used to parse or format strings for consumption by APIs that don't care about the user's locale. So we need to pick a locale and stick with it, or the code will break depending on whose browser it runs in. There's an exception, though: `DateTime#toFormat` can take \"macro\" formats like \"D\" that produces localized strings as part of a larger string. These *do* default to the system locale because their entire purpose is to be provide localized strings.\n\n### Setting the default\n\nYou can set a default locale so that new instances will always be created with the specified locale:\n\n```js\nSettings.defaultLocale = \"fr\";\nDateTime.now().locale; //=> 'fr'\n```\n\nNote that this also alters the behavior of `DateTime#toFormat` and `DateTime#fromFormat`.\n\n### Using the system locale in string parsing\n\nYou generally don't want `DateTime#fromFormat` and `DateTime#toFormat` to use the system's locale, since your format won't be sensitive to the locale's string ordering. That's why Luxon doesn't behave that way by default. But if you really want that behavior, you can always do this:\n\n```js\nSettings.defaultLocale = DateTime.now().resolvedLocaleOptions().locale;\n```\n\n## Checking what you got\n\nThe local environment may not support the exact locale you asked for. The native Intl API will try to find the best match. If you want to know what that match was, use `resolvedLocaleOpts`:\n\n```js\nDateTime.local({ locale: \"fr-co\" }).resolvedLocaleOptions(); //=> { locale: 'fr',\n// numberingSystem: 'latn',\n// outputCalendar: 'gregory' }\n```\n\n## Methods affected by the locale\n\n### Formatting\n\nThe most important method affected by the locale setting is `toLocaleString`, which allows you to produce internationalized, human-readable strings.\n\n```js\ndt.setLocale(\"fr\").toLocaleString(DateTime.DATE_FULL); //=> '25 septembre 2017'\n```\n\nThat's the normal way to do it: set the locale as property of the DateTime itself and let the `toLocaleString` inherit it. But you can specify the locale directly to `toLocaleString` too:\n\n```js\ndt.toLocaleString({ locale: \"es\" , ...DateTime.DATE_FULL }); //=> '25 de septiembre de 2017'\n```\n\nAd-hoc formatting also respects the locale:\n\n```js\ndt.setLocale(\"fr\").toFormat(\"MMMM dd, yyyy GG\"); //=> 'septembre 25, 2017 après Jésus-Christ'\n```\n\n### Parsing\n\nYou can [parse](parsing.md) localized strings:\n\n```js\nDateTime.fromFormat(\"septembre 25, 2017 après Jésus-Christ\", \"MMMM dd, yyyy GG\", { locale: \"fr\" });\n```\n\n### Listing\n\nSome of the methods in the `Info` class let you list strings like months, weekdays, and eras, and they can be localized:\n\n```js\nInfo.months(\"long\", { locale: \"fr\" }); //=> [ 'janvier', 'février', ...\nInfo.weekdays(\"long\", { locale: \"fr\" }); //=> [ 'lundi', 'mardi', ...\nInfo.eras(\"long\", { locale: \"fr\" }); //=> [ 'avant Jésus-Christ', 'après Jésus-Christ' ]\n```\n\n## numberingSystem\n\nDateTimes also have a `numberingSystem` setting that lets you control what system of numerals is used in formatting. In general, you shouldn't override the numbering system provided by the locale. For example, no extra work is needed to get Arabic numbers to show up in Arabic-speaking locales:\n\n```js\nvar dt = DateTime.now().setLocale(\"ar\");\n\ndt.resolvedLocaleOptions(); //=> { locale: 'ar',\n// numberingSystem: 'arab',\n// outputCalendar: 'gregory' }\n\ndt.toLocaleString(); //=> '٢٤/٩/٢٠١٧'\n```\n\nFor this reason, Luxon defaults its own `numberingSystem` property to null, by which it means \"let the Intl API decide\". However, you can override it if you want. This example is admittedly ridiculous:\n\n```js\nconst dt = DateTime.local().reconfigure({ locale: \"it\", numberingSystem: \"beng\" });\ndt.toLocaleString(DateTime.DATE_FULL); //=> '২৪ settembre ২০১৭'\n```\n\nSimilar to `locale`, you can set the default numbering system for new instances:\n\n```js\nSettings.defaultNumberingSystem = \"beng\";\n```\n\n## Locale-based weeks\n\nMost of Luxon uses the [ISO week date](https://en.wikipedia.org/wiki/ISO_week_date) system when working with week-related data.\nThis means that the week starts on Monday and the first week of the year is that week, which has 4 or more of its days in January.\n\nThis definition works for most use-cases, however locales can define different rules. For example, in many English-speaking countries\nthe week is said to start on Sunday and the 1 January always defines the first week of the year. This information is\navailable through the Luxon as well.\n\nNote that your runtime needs to support [`Intl.Locale#getWeekInfo`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/Locale/getWeekInfo) for this to have an effect. If unsupported, Luxon will fall back\nto using the ISO week dates.\n\n### Accessing locale-based week info\n\nThe `Info` class exposes methods `getStartOfWeek`, `getMinimumDaysInFirstWeek` and `getWeekendWeekdays` for informational\npurposes.\n\n### Accessing locale-based week data\n\n```js\nconst dt = DateTime.local(2022, 1, 1, { locale: \"en-US\" });\ndt.localWeekday // 7, because Saturday is the 7th day of the week in en-US\ndt.localWeekNumber // 1, because 1 January is always in the first week in en-US\ndt.localWeekYear // 2022, because 1 January is always in the first week in en-US\ndt.weeksInLocalWeekYear // 53, because 2022 has 53 weeks in en-US\n```\n\n### Using locale-based week data when creating DateTimes\n\nWhen creating a DateTime instance using `fromObject`, you can use the `localWeekday`, `localWeekNumber` and `localWeekYear`\nproperties. They will use the same locale that the newly created DateTime will use, either explicitly provided or falling back\nto the system default.\n\n```js\nconst dt = DateTime.fromObject({localWeekYear: 2022, localWeekNumber: 53, localWeekday: 7});\ndt.toISODate(); // 2022-12-31\n```\n\n### Setting locale-based week data\n\nWhen modifying an existing DateTime instance using `set`, you can use the `localWeekday`, `localWeekNumber` and `localWeekYear`\nproperties. They will use the locale of the existing DateTime as reference.\n\n```js\nconst dt = DateTime.local(2022, 1, 2, { locale: \"en-US\" });\nconst modified = dt.set({localWeekNumber: 2});\nmodified.toISODate(); // 2022-01-08\n```\n\n### Locale-based weeks with math\n\nThe methods `startOf`, `endOf`, `hasSame` of `DateTime` as well as `count` of `Interval` accept an option `useLocaleWeeks`. \nIf enabled, the methods will treat the `week` unit according to the locale, respecting the correct start of the week.\n\n```js\nconst dt = DateTime.local(2022, 1, 6, { locale: \"en-US\" });\nconst startOfWeek = dt.startOf('week', {useLocaleWeeks: true});\nstartOfWeek.toISODate(); // 2022-01-02, a Sunday\n```\n\n### Overriding defaults\n\nYou can override the runtime-provided defaults for the week settings using `Settings.defaultWeekSettings`:\n\n```js\nSettings.defaultWeekSettings = { firstDay: 7, minimalDays: 1, weekend: [6, 7] }\n```"
},
{
"path": "docs/math.md",
"content": "# Math\n\nThis page covers some oddball topics related to date and time math, which has some quirky corner cases.\n\n## Calendar math vs time math\n\n### The basics\n\nMath with dates and times can be unintuitive to programmers. If it's Feb 13, 2017 and I say \"in exactly one month\", you know I mean March 13. Exactly one month after that is April 13. But because February is a shorter month than March, that means we added a different amount of time in each case. On the other hand, if I said \"30 days from February 13\", you'd try to figure out what day that landed on in March. Here it is in Luxon:\n\n```js\nDateTime.local(2017, 2, 13).plus({ months: 1 }).toISODate() //=> '2017-03-13'\n\nDateTime.local(2017, 2, 13).plus({ days: 30 }).toISODate() //=> '2017-03-15'\n```\n\nMore generally we can differentiate two modes of math:\n\n * Calendar math works with higher-order, variable-length units like years and months\n * Time math works with lower-order, constant-length units such as hours, minutes, and seconds.\n\n### Which units use which math?\n\nThese units use calendar math:\n\n * **Years** vary because of leap years.\n * **Months** vary because they're just different lengths.\n * **Days** vary because DST transitions mean some days are 23 or 25 hours long.\n * **Quarters** are always three months, but months vary in length so quarters do too.\n * **Weeks** are always the same number of days, but days vary so weeks do too.\n \nThese units use time math:\n\n * **Hours** are always 60 minutes\n * **Minutes** are always 60 seconds\n * **Seconds** are always 1000 milliseconds\n\n### Leap seconds\n\nLuxon ([as JavaScript in general](https://262.ecma-international.org/5.1/#sec-15.9.1.1)) doesn't account for [leap seconds](https://en.wikipedia.org/wiki/Leap_second); as in most programming environments, leap seconds happen as invisible changes to the underlying system's time. This can, in rare cases, cause the same second to \"occur\" twice from Luxon's perspective.\n\nThe practical effect of leaps seconds are quite limited:\n\n1. You can't represent the leap second itself (i.e., `DateTime.utc(2016, 12, 31, 23, 59, 60).isValid` returns `false`).\n2. A Luxon `diff()` calculation that crosses a leap second will not exactly match the number of seconds that passed in the outside world. This can come up in rare situations where it matters to your application exactly what happened in the last *n* seconds. Even this is increasingly mitigated by [leap smear](https://developers.google.com/time/smear).\n\n### How to think about calendar math\n\nIt's best not to think of calendar math as requiring arcane checks on the lengths of intervening periods. Instead, think of them as **adjusting that unit directly and keeping lower order date components constant**. Let's go back to the Feb 13 + 1 month example. If you didn't have Luxon, you would do something like this to accomplish that:\n\n```js\nvar d = new Date('2017-02-13')\nd.setMonth(d.getMonth() + 1)\nd.toLocaleString() //=> '3/13/2017, 12:00:00 AM'\n```\n\nAnd under the covers, that's more or less what Luxon does too. It doesn't boil the operation down to a milliseconds delta because that's not what's being asked. Instead, it fiddles with what it thinks the date should be and then uses the built-in Gregorian calendar to compute the new timestamp.\n\n### DSTs\n\nThere's a whole section about this in the [time zones documentation](zones.md?id=math-across-dsts). But here's a quick example (Spring Forward is early on March 12 in my time zone):\n\n```js\nvar start = DateTime.local(2017, 3, 11, 10);\nstart.hour //=> 10, just for comparison\nstart.plus({days: 1}).hour //=> 10, stayed the same\nstart.plus({hours: 24}).hour //=> 11, DST pushed forward an hour\n```\n\nSo in adding a day, we kept the hour at 10, even though that's only 23 hours later.\n\n### Time math\n\nTime math is different. In time math, we're just adjusting the clock, adding or subtracting from the epoch timestamp. Adding 63 hours is really the same as adding 63 hours' worth of milliseconds. Under the covers, Luxon does this exactly the opposite of how it does calendar math; it boils the operation down to milliseconds, computes the new timestamp, and then computes the date out of that.\n\n## Math with multiple units\n\nIt's possible to do math with multiple units:\n\n```js\nDateTime.fromISO('2017-05-15').plus({months: 2, days: 6}).toISODate(); //=> '2017-07-21'\n```\n\nThis isn't as simple as it looks. For example, what should you expect this to do?\n\n```js\nDateTime.fromISO('2017-04-30').plus({months: 1, days: 1}).toISODate();\n```\n\nIf the day is added first, we'll get an intermediate value of May 1. Adding a month to that gives us June 1. But if the month is added first, we'll an intermediate value of May 30 and day after that is May 31. (See \"Calendar math vs time math\" above if this is confusing.) So the order matters.\n\nLuxon has a simple rule for this: **math is done from highest order to lowest order**. So the result of the example above is May 31. This rule isn't logically necessary, but it does seem to reflect what people mean. Of course, Luxon can't enforce this rule if you do the math in separate operations:\n\n```js\nDateTime.fromISO('2017-04-30').plus({days: 1}).plus({months: 1}).toISODate() //=> '2017-06-01'\n```\n\nIt's not a coincidence that Luxon's interface makes it awkward to do this wrong.\n\n## Comparing DateTimes\n\nDateTime implements `#valueOf` to return the epoch timestamp, so you can compare DateTimes with `<`, `>`, `<=`, and `>=`. That lets you find out if one DateTime is after or before another DateTime.\n\n```js\nd1 < d2 // is d1 before d2?\n```\n\nHowever, be aware that `===` compares object identity, which is not a useful concept in a library with immutable types. Use `#equals` to compare both the time and additional metadata, such as the locale and time zone. If you're only interested in checking the equality of the timestamps, you can use:\n\n```js\nd1.toMillis() === d2.toMillis() // are d1 and d2 the same instant in time?\n+d1 === +d2 // same test, using object coercion\n```\n\nYou may also use `#hasSame` to make more subtle comparisons:\n\n```js\nd1.hasSame(d2, 'year'); // both DateTimes have the same calendar year\nd1.hasSame(d2, 'day'); // both DateTimes have the same calendar day (which implies they also have the same calendar year and month)\n```\n\nNote that these are checking against the calendar. For example, if `d1` is in 2017, calling `hasSame` with \"year\" asks if d2 is also in 2017, not whether the DateTimes within a year of each other. For that, you'd need `diff` (see below).\n\nIf you'd like to compare using a specific unit, you can achieve this by combining `#startOf` and the `#valueOf` comparisons above.\n\n```js\nvar d1 = DateTime.fromISO('2017-04-30');\nvar d2 = DateTime.fromISO('2017-04-01');\n\nd2 < d1 //=> true\nd2.startOf('year') < d1.startOf('year') //=> false\nd2.startOf('month') < d1.startOf('month') //=> false\nd2.startOf('day') < d1.startOf('day') //=> true\n```\n\n## Duration math\n\n### Basics\n\n`Durations` are quantities of time, like \"3 days and 6 hours\". Luxon has no idea *which* 3 days and 6 hours they represent; it's just how Luxon represents those quantities in abstract, unmoored from the timeline. This is both tremendously useful and occasionally confusing. I'm not going to give a detailed tour of their capabilities here (see the API docs for that), but I do want to clear up some of those confusions.\n\nHere's some very basic stuff to get us going:\n\n```js\nvar dur = Duration.fromObject({ days: 3, hours: 6})\n\n// examine it\ndur.toObject() //=> { days: 3, hours: 6 }\n\n// express in minutes\ndur.as('minutes') //=> 4680\n\n// convert to minutes\ndur.shiftTo('minutes').toObject() //=> { minutes: 4680 }\n\n// add to a DateTime\nDateTime.fromISO(\"2017-05-15\").plus(dur).toISO() //=> '2017-05-18T06:00:00.000-04:00'\n```\n\n### Diffs\n\nYou can subtract one time from another to find out how much time there is between them. Luxon's `DateTime.diff` method does this and it returns a Duration. For example:\n\n```js\nvar end = DateTime.fromISO('2017-03-13');\nvar start = DateTime.fromISO('2017-02-13');\n\nvar diffInMonths = end.diff(start, 'months');\ndiffInMonths.toObject(); //=> { months: 1 }\n```\n\nNotice we had to pick the unit to keep track of the diff in. The default is milliseconds:\n\n```js\nvar diff = end.diff(start);\ndiff.toObject() //=> { milliseconds: 2415600000 }\n```\n\nFinally, you can diff using multiple units:\n\n```js\nvar end = DateTime.fromISO('2017-03-13');\nvar start = DateTime.fromISO('2017-02-11');\nend.diff(start, ['months', 'days']).toObject() //=> { months: 1, days: 2 }\n```\n\n### Casual vs longterm conversion accuracy\n\nDurations represent bundles of time with specific units, but Luxon allows you to convert between them:\n\n * `shiftTo` returns a new Duration denominated in the specified units.\n * `as` converts the duration to just that unit and returns its value\n\n```js\nvar dur = Duration.fromObject({ months: 4, weeks: 2, days: 6 })\n\ndur.as('days') //=> 140\ndur.shiftTo('days').toObject() //=> { days: 140 }\ndur.shiftTo('weeks', 'hours').toObject() //=> { weeks: 18, hours: 144 }\n```\n\nBut how do those conversions actually work? First, uncontroversially:\n\n * 1 week = 7 days\n * 1 day = 24 hours\n * 1 hour = 60 minutes\n * 1 minute = 60 seconds\n * 1 second = 1000 milliseconds\n \nThese are always true and you can roll them up and down with consistency (e.g. `1 hour = 60 * 60 * 1000 milliseconds`). However, this isn't really true for the higher order units, which vary in length, even putting DSTs aside. A year is sometimes 365 days long and sometimes 366. Months are 28, 29, 30, or 31 days. By default Luxon converts between these units using what you might call \"casual\" conversions:\n\n| | Month | Week | Day |\n| --- | --- | --- | --- |\n| Year | 12 | 52 | 365 |\n| Quarter | 3 | 13 | 91 |\n| Month | | 4 | 30 |\n\nThese should match your intuition and for most purposes they work well. But they're not just wrong; they're not even self-consistent:\n\n```js\nDuration.fromObject({ years:1 }).shiftTo('months').shiftTo('days').as('years') //=> 0.9863013698630136\n```\n\nThis is because 12 * 30 != 365. These errors can be annoying, but they can also cause significant issues if the errors accumulate:\n\n```js\nvar dur = Duration.fromObject({ years: 50000 });\nDateTime.now().plus(dur.shiftTo('milliseconds')).year //=> 51984\nDateTime.now().plus(dur).year //=> 52017\n```\n\nThose are 33 years apart! So Luxon offers an alternative conversion scheme called \"longterm\", based on the 400-year calendar cycle:\n\n| | Month | Week | Day |\n|---- | --- | --- | --- |\n| Year | 12 | 52.1775 | 365.2425 |\n| Quarter | 3 | 13.04435 | 91.310625 |\n| Month | | 4.348125 | 30.436875 |\n\nYou can see why these are irritating to work with, which is why they're not the default.\n\nLuxon methods that create Durations de novo accept an option called `conversionAccuracy`. You can set it to \"casual\" or \"longterm\". It's a property of the Duration itself, so any conversions you do use the rule you've picked, and any new Durations you derive from it will retain that property.\n\n```js\nDuration.fromObject({ years: 23 }, { conversionAccuracy: 'longterm' });\nDuration.fromISO('PY23', { conversionAccuracy: 'longterm' });\n\nend.diff(start, 'days', { conversionAccuracy: 'longterm' })\n```\n\nYou can also create an accurate Duration out of an existing one:\n\n```js\nvar pedanticDuration = casualDuration.reconfigure({ conversionAccuracy: 'longterm' });\n```\n\nThese Durations will do their conversions differently.\n\n\n### Losing information\n\nBe careful of converting between units. It's easy to lose information. Let's say we converted a diff into days:\n\n\n```js\nvar end = DateTime.fromISO('2017-03-13');\nvar start = DateTime.fromISO('2017-02-13');\n\nvar diffInMonths = end.diff(start, 'months');\ndiffInMonths.as('days'); //=> 30\n```\n\nThat's our conversion between months and days (you could also do a longterm-accurate conversion; it wouldn't fix the issue ahead). But this isn't the number of days between February 13 and March 13!\n\n```js\nvar diffInDays = end.diff(start, 'days');\ndiffInDays.toObject(); //=> { days: 28 }\n```\n\nIt's important to remember that diffs are Duration objects, and a Duration is just a dumb pile of time units our computation spat out. Unlike an Interval, a Duration doesn't \"remember\" what the inputs to the diff were. So we lost some information converting between units. This mistake is really common when rolling up:\n\n\n```js\nvar diff = end.diff(start); // default unit is milliseconds\n\n// wtf, that's not a month!\ndiff.as('months'); //=> 0.9319444 \n\n// it's not even the right number of days! (hint: my time zone has a DST)\ndiff.shiftTo('hours').as('days'); //=> 27.958333333333332\n```\n\nNormally you won't run into this problem if you think clearly about what you want to do with a diff. Specifically, make sure you diff in the units you actually want to use. Then Luxon knows to answer the question you really want to ask.\n\n```js\nvar monthsDiff = end.diff(start, \"months\");\nvar daysDiff = end.diff(start, \"days\");\n```\n\nBut sometimes you really do want an object that represents the subtraction itself, not the result. `Intervals` can help. Intervals are mostly used to keep track of ranges of time, but they make for \"anchored\" diffs too. For example:\n\n```js\nvar end = DateTime.fromISO('2017-03-13');\nvar start = DateTime.fromISO('2017-02-13');\nvar i = Interval.fromDateTimes(start, end);\n\ni.length('days'); //=> 28\ni.length('months') //=> 1\n```\n\nBecause the Interval stores its endpoints and computes `length` on the fly, it retakes the diff each time you query it. Of course, precisely because an Interval *isn't* an abstract bundle of time, it can't be used in places where Durations can. For example, you can't add them to DateTime via `plus()` because Luxon wouldn't know what units to do the math in (see \"Calendar vs time math\" above). But you can convert the interval into a Duration by picking the units:\n\n```js\ni.toDuration('months').toObject(); //=> { months: 1 }\ni.toDuration('days').toObject(); //=> { days: 28 }\n```\n\nYou can even pick multiple units:\n\n```js\nend = DateTime.fromISO('2018-05-25');\ni = start.until(end);\ni.toDuration(['years', 'months', 'days']).toObject(); //=> { years: 1, months: 3, days: 12 }\n```\n\nOf course, once you've converted to a Duration, you're back in the same spot you were with the diff case; *further* conversions will be lossy. So the point is to think carefully about what information you have when.\n"
},
{
"path": "docs/matrix.md",
"content": "# Support matrix\n\nThis page covers what platforms are supported by Luxon and what caveats apply to them.\n\n## Official support\n\nLuxon officially supports the last two versions of the major browsers, with some caveats. The table below shows which of the not-universally-supported features are available in what environments.\n\n| Browser | Versions | Intl relative time formatting |\n| -------------------------------- | -------- | ----------------------------- |\n| Chrome | >= 73 | ✓ |\n| Firefox | >= 65 | ✓ |\n| Edge | >= 79 | ✓ |\n| | 18 | ✗ |\n| Safari | >= 14 | ✓ |\n| | 13 | ✗ |\n| iOS Safari (iOS version numbers) | >= 14 | ✓ |\n| Node | >= 12 | ✓ |\n\n- Those capabilities are explained in the next sections, along with possible polyfill options\n- \"w/ICU\" refers to providing Node with ICU data. See the [install](install.md?id=node) for instructions\n\n## Effects of missing features\n\n**If the platforms you're targeting has all its boxes above check off, ignore this section**.\n\nIn the support table above, you can see that some environments are missing capabilities. In the current version of\nLuxon, there's only one partially-supported feature, so this is currently pretty simple. (Older versions of Luxon supported\nolder browsers, so there were nuanced feature caveats. Newer versions will add more caveats as new browser capabilities\nbecome available and Luxon takes advantage of them if they're present.)\n\n1. **Relative time formatting**. Luxon's support for relative time formatting (e.g. `DateTime#toRelative` and `DateTime#toRelativeCalendar`) depends on Intl.RelativeTimeFormat. Luxon will fall back to using English if that capability is missing.\n\nIf the browser lacks these capabilities, Luxon tries its best:\n\n| Feature | Full support | No relative time format |\n| -------------------------------------- | ------------ | ----------------------- |\n| Most things | OK | OK |\n| `DateTime#toRelative` in en-US | OK | OK |\n| `DateTime#toRelative` in other locales | Uses English | Uses English |\n\n\n## Older platforms\n\n- **Older versions of both Chrome and Firefox** will most likely work. It's just that I only officially support the last two versions. As you get to older versions of these browsers, the missing capabilities listed above begin to apply to them. (e.g. FF started supporting `formatToParts` in 51 and time zones in 52). I haven't broken that out because it's complicated, Luxon doesn't officially support them, and no one runs them anyway.\n- **Older versions of IE** probably won't work at all.\n- **Older versions of Node** probably won't work without recompiling Luxon with a different Node target. In which case they'll work with some features missing.\n\n## Other platforms\n\nIf the platform you're targeting isn't on the list and you're unsure what caveats apply, you can check which pieces are supported:\n\n```js\nInfo.features(); //=> { relative: false }\n```\n\nSpecific notes on other platforms:\n\n- **React Native <0.70 on (specifically) Android** doesn't include Intl support by default, so all the possible-to-be-missing capabilities above are unavailable. To fix this on React Native >=0.60, you should configure the build flavor of jsc in `android/app/build.gradle`:\n\n```diff\n-def jscFlavor = 'org.webkit:android-jsc:+'\n+def jscFlavor = 'org.webkit:android-jsc-intl:+'\n```\n\nFor even older versions of React Native you can use [jsc-android-buildscripts](https://github.com/SoftwareMansion/jsc-android-buildscripts) to fix it.\n"
},
{
"path": "docs/moment.md",
"content": "# For Moment users\n\nLuxon borrows lots of ideas from [Moment.js](https://momentjs.com), but there are a lot of differences too. This document clarifies what they are.\n\n## Immutability\n\nLuxon's objects are immutable, whereas Moment's are mutable. For example, in Moment:\n\n```js\nvar m1 = moment();\nvar m2 = m1.add(1, 'hours');\nm1.valueOf() === m2.valueOf(); //=> true\n```\n\nThis happens because `m1` and `m2` are really the same object; `add()` *mutated* the object to be an hour later. Compare that to Luxon:\n\n```js\nvar d1 = DateTime.now();\nvar d2 = d1.plus({ hours: 1 });\nd1.valueOf() === d2.valueOf(); //=> false\n```\n\nThis happens because the `plus` method returns a new instance, leaving `d1` unmodified. It also means that Luxon doesn't require copy constructors or clone methods.\n\n## Major functional differences\n\n1. Months in Luxon are 1-indexed instead of 0-indexed like in Moment and the native Date type.\n1. Localizations and time zones are implemented by the native Intl API (or a polyfill of it), instead of by the library itself.\n1. Luxon has both a Duration type and an Interval type. The Interval type is like Twix.\n\n## Other API style differences\n\n1. Luxon methods often take option objects as their last parameter\n1. Luxon has different static methods for object creation (e.g. `fromISO`), as opposed to Moment's one function that dispatches based on the input\n1. Luxon parsers are very strict, whereas Moment's are more lenient.\n1. Luxon uses getters instead of accessor methods, so `dateTime.year` instead of `dateTime.year()`\n1. Luxon centralizes its \"setters\", like `dateTime.set({year: 2016, month: 4})` instead of `dateTime.year(2016).month(4)` like in Moment.\n1. Luxon's Durations are a separate top-level class.\n1. Arguments to Luxon's methods are not automatically coerced into Luxon instances. E.g. `m.diff('2017-04-01')` would be `dt.diff(DateTime.fromISO('2017-04-01'))`.\n\n## DateTime method equivalence\n\nHere's a rough mapping of DateTime methods in Moment to ones in Luxon. I haven't comprehensively documented stuff that's in Luxon but not in Moment, just a few odds and ends that seemed obvious for inclusion; there are more. I've probably missed a few things too.\n\n### Creation\n\n| Operation | Moment | Luxon | Notes |\n| ----------------------- | ------------------------ | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |\n| Now | `moment()` | `DateTime.now()` | |\n| From ISO | `moment(String)` | `DateTime.fromISO(String)` | |\n| From RFC 2822 | `moment(String)` | `DateTime.fromRFC2822(String)` | |\n| From custom format | `moment(String, String)` | `DateTime.fromFormat(String, String)` | The format tokens differ between Moment and Luxon, such that the same format string cannot be used between the two. |\n| From object | `moment(Object)` | `DateTime.fromObject(Object)` | |\n| From timestamp | `moment(Number)` | `DateTime.fromMillis(Number)` | |\n| From JS Date | `moment(Date)` | `DateTime.fromJSDate(Date)` | |\n| From civil time | `moment(Array)` | `DateTime.local(Number...)` | Like `DateTime.local(2016, 12, 25, 10, 30)` |\n| From UTC civil time | `moment.utc(Array)` | `DateTime.utc(Number...)` | Moment also uses `moment.utc()` to take other arguments. In Luxon, use the appropriate method and pass in the `{ zone: 'utc'}` option |\n| Clone | `moment(Moment)` | N/A | Immutability makes this pointless; just reuse the object |\n| Use the string's offset | `parseZone` | See note | Methods taking strings that can specify offset or zone take a `setZone` argument |\n\n### Getters and setters\n\n#### Basic information getters\n\n| Property | Moment | Luxon | Notes |\n| -------- | ----------- | --------- | ------------------------------------------------ |\n| Validity | `isValid()` | `isValid` | See also `invalidReason` |\n| Locale | `locale()` | `locale` | |\n| Zone | `tz()` | `zone` | Moment requires a plugin for this, but not Luxon |\n\n#### Unit getters\n\n| Property | Moment | Luxon | Notes |\n| ---------------------- | ------------------------------------ | ------------- | -------------------------------------- |\n| Year | `year()` | `year` | |\n| Month | `month()` | `month` | |\n| Day of month | `date()` | `day` | |\n| Day of week | `day()`, `weekday()`, `isoWeekday()` | `weekday` | 1-7, Monday is 1, Sunday is 7, per ISO |\n| Day of year | `dayOfYear()` | `ordinal` | |\n| Hour of day | `hour()` | `hour` | |\n| Minute of hour | `minute()` | `minute` | |\n| Second of minute | `second()` | `second` | |\n| Millisecond of seconds | `millisecond()` | `millisecond` | |\n| Week of ISO week year | `weekYear`, `isoWeekYear` | `weekYear` | |\n| Quarter | `quarter` | None | Just divide the months by 3 |\n\n#### Programmatic get and set\n\nFor programmatic getting and setting, Luxon and Moment are very similar here:\n\n| Operation | Moment | Luxon | Notes |\n| ---------- | --------------------- | ------------- | --------------------------------------- |\n| get value | `get(String)` | `get(String)` | |\n| set value | `set(String, Number)` | None | |\n| set values | `set(Object)` | `set(Object)` | Like `dt.set({ year: 2016, month: 3 })` |\n\n### Transformation\n\n| Operation | Moment | Luxon | Notes |\n| ------------------ | -------------------------- | ------------------- | --------------------------------------- |\n| Addition | `add(Number, String)` | `plus(Object)` | Like `dt.plus({ months: 3, days: 2 })` |\n| Subtraction | `subtract(Number, String)` | `minus(Object)` | Like `dt.minus({ months: 3, days: 2 })` |\n| Start of unit | `startOf(String)` | `startOf(String)` | |\n| End of unit | `endOf(String)` | `endOf(String)` | |\n| Change unit values | `set(Object)` | `set(Object)` | Like `dt.set({ year: 2016, month: 3 })` |\n| Change time zone | `tz(String)` | `setZone(string)` | Luxon doesn't require a plugin |\n| Change zone to utc | `utc()` | `toUTC()` | |\n| Change local zone | `local()` | `toLocal()` | |\n| Change offset | `utcOffset(Number)` | None | Set the zone instead |\n| Change locale | `locale(String)` | `setLocale(String)` | |\n\n### Query\n\n| Question | Moment | Luxon | Notes |\n| ------------------------------------------ | ----------------------- | ------------------------------------------------ | ----------------------------------------------------------------------------------------------- |\n| Is this time before that time? | `m1.isBefore(m2)` | `dt1 < dt2` | The Moment versions of these take a unit. To do that in Luxon, use `startOf` on both instances. |\n| Is this time after that time? | `m1.isAfter(m2)` | `dt1 > dt2` | |\n| Is this time the same or before that time? | `m1.isSameOrBefore(m2)` | `dt1 <= dt2` | |\n| Is this time the same or after that time? | `m1.isSameOrAfter(m2)` | `dt1 >= dt2` | |\n| Do these two times have the same [unit]? | `m1.isSame(m2, unit)` | `dt1.hasSame(dt2, unit)` | |\n| Is this time's [unit] before that time's? | `m1.isBefore(m2, unit)` | `dt1.startOf(unit) < dt2.startOf(unit)` | |\n| Is this time's [unit] after that time's? | `m1.isAfter(m2, unit)` | `dt1.startOf(unit) > dt2.startOf(unit)` | |\n| Is this time between these two times? | `m1.isBetween(m2, m3)` | `Interval.fromDateTimes(dt2, dt3).contains(dt1)` | |\n| Is this time inside a DST | `isDST()` | `isInDST` | |\n| Is this time's year a leap year? | `isInLeapYear()` | `isInLeapYear` | |\n| How many days are in this time's month? | `daysInMonth()` | `daysInMonth` | |\n| How many days are in this time's year? | None | `daysInYear` | |\n\n### Output\n\n#### Basics\n\nSee the [formatting guide](formatting.md) for more about the string-outputting methods.\n\n| Output | Moment | Luxon | Notes |\n| ---------------- | -------------- | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |\n| simple string | `toString()` | `toString()` | Luxon just uses ISO 8601 for this. See Luxon's `toLocaleString()` |\n| full ISO 8601 | `iso()` | `toISO()` | |\n| ISO date only | None | `toISODate()` | |\n| ISO time only | None | `toISOTime()` | |\n| custom format | `format(...)` | `toFormat(...)` | The format tokens differ between Moment and Luxon, such that the same format string cannot be used between the two. Note `toFormat` is meant to be used for machine-readable formats. For anything human-readable, you really want to use `toLocaleString()` instead. |\n| RFC 2822 | | `toRFC2822()` | |\n| HTTP date string | | `toHTTP()` | |\n| JS Date | `toDate()` | `toJSDate()` | |\n| Epoch time | `valueOf()` | `toMillis()` or `valueOf()` | |\n| Object | `toObject()` | `toObject()` | |\n| Duration | `diff(Moment)` | `diff(DateTime)` | Moment's diff returns a count of milliseconds, but Luxon's returns a Duration. To replicate the Moment behavior, use `dt1.diff(d2).milliseconds`. |\n\n#### Humanization\n\nLuxon has `toRelative` and `toRelativeCalendar`. For internationalization, they use Intl.RelativeTimeFormat (or fall back to English when it is not supported by the browser).\n\n| Operation | Moment | Luxon |\n| -------------------- | -------------- | --------------------------------------------- |\n| Time from now | `fromNow()` | `toRelative()` |\n| Time from other time | `from(Moment)` | `toRelative({ base: DateTime })` |\n| Time to now | `toNow()` | `DateTime.local().toRelative({ base: this })` |\n| Time to other time | `to(Moment)` | `otherTime.toRelative({ base: this })` |\n| \"Calendar time\" | `calendar()` | `toRelativeCalendar()` |\n\n## Durations\n\nMoment Durations and Luxon Durations are broadly similar in purpose and capabilities. The main differences are:\n\n1. Luxon durations have more sophisticated conversion capabilities. They can convert from one set of units to another using `shiftTo`. They can also be configured to use different unit conversions. See [Duration Math](math.md?id=duration-math) for more.\n1. Luxon does not (yet) have an equivalent of Moment's Duration `humanize` method. Luxon will add that when [Intl.UnitFormat](https://github.com/tc39/proposal-intl-unit-format) is supported by browsers.\n1. Like DateTimes, Luxon Durations have separate methods for creating objects from different sources.\n\nSee the `Duration` API docs for more.\n\n## Intervals\n\nMoment doesn't have direct support intervals, which must be provided by plugins like Twix or moment-range. Luxon's Intervals have similar capabilities to theirs, with the exception of the humanization features. See the `Interval` API docs for more.\n"
},
{
"path": "docs/parsing.md",
"content": "# Parsing\n\nLuxon is not an NLP tool and isn't suitable for all date parsing jobs. But it can do some parsing:\n\n1. Direct support for several well-known formats, including most valid ISO 8601 formats\n2. An ad-hoc parser for parsing specific formats\n\n## Parsing technical formats\n\n### ISO 8601\n\nLuxon supports a wide range of valid ISO 8601 formats through the `fromISO` method.\n\n```js\nDateTime.fromISO(\"2016-05-25\");\n```\n\nAll of these are parsable by `fromISO`:\n\n```\n2016\n2016-05\n201605\n2016-05-25\n20160525\n2016-05-25T09\n2016-05-25T09:24\n2016-05-25T09:24:15\n2016-05-25T09:24:15.123\n2016-05-25T0924\n2016-05-25T092415\n2016-05-25T092415.123\n2016-05-25T09:24:15,123\n2016-W21-3\n2016W213\n2016-W21-3T09:24:15.123\n2016W213T09:24:15.123\n2016-200\n2016200\n2016-200T09:24:15.123\n09:24\n09:24:15\n09:24:15.123\n09:24:15,123\n```\n\n- In addition, all the times support offset arguments like \"Z\" and \"+06:00\".\n- Missing lower-order values are always set to the minimum possible value; i.e. it always parses to a full DateTime. For example, \"2016-05-25\" parses to midnight of that day. \"2016-05\" parses to the first of the month, etc.\n- The time is parsed as a local time if no offset is specified, but see the method docs to see your options, and also check out [time zone docs](zones.md) for more details.\n\n### HTTP and RFC2822\n\nLuxon also provides parsing for strings formatted according to RFC 2822 and the HTTP header specs (RFC 850 and 1123):\n\n```js\nDateTime.fromRFC2822(\"Tue, 01 Nov 2016 13:23:12 +0630\");\nDateTime.fromHTTP(\"Sunday, 06-Nov-94 08:49:37 GMT\");\nDateTime.fromHTTP(\"Sun, 06 Nov 1994 08:49:37 GMT\");\n```\n\n### SQL\n\nLuxon accepts SQL dates, times, and datetimes, via `fromSQL`:\n\n```js\nDateTime.fromSQL(\"2017-05-15\");\nDateTime.fromSQL(\"2017-05-15 09:24:15\");\nDateTime.fromSQL(\"09:24:15\");\n```\n\nIt works similarly to `fromISO`, so see above for additional notes.\n\n### Unix timestamps\n\nLuxon can parse numerical [Unix timestamps](https://en.wikipedia.org/wiki/Unix_time):\n\n```js\nDateTime.fromMillis(1542674993410);\nDateTime.fromSeconds(1542674993);\n```\n\nBoth methods accept the same options, which allow you to specify a timezone, calendar, and/or numbering system.\n\n### JS Date Object\n\nA native JS `Date` object can be converted into a `DateTime` using `DateTime.fromJSDate`.\n\nAn optional `zone` parameter can be provided to set the zone on the resulting object.\n\n\n## Ad-hoc parsing\n\n### Consider alternatives\n\nYou generally shouldn't use Luxon to parse arbitrarily formatted date strings:\n\n1. If the string was generated by a computer for programmatic access, use a standard format like ISO 8601. Then you can parse it using `DateTime.fromISO`.\n2. If the string is typed out by a human, it may not conform to the format you specify when asking Luxon to parse it. Luxon is quite strict about the format matching the string exactly.\n\nSometimes, though, you get a string from some legacy system in some terrible ad-hoc format and you need to parse it.\n\n### fromFormat\n\nSee `DateTime.fromFormat` for the method signature. A brief example:\n\n```js\nDateTime.fromFormat(\"May 25 1982\", \"LLLL dd yyyy\");\n```\n\n### Intl\n\nLuxon supports parsing internationalized strings:\n\n```js\nDateTime.fromFormat(\"mai 25 1982\", \"LLLL dd yyyy\", { locale: \"fr\" });\n```\n\nNote, however, that Luxon derives the list of strings that can match, say, \"LLLL\" (and their meaning) by introspecting the environment's Intl implementation. Thus the exact strings may in some cases be environment-specific. You also need the Intl API available on the target platform (see the [support matrix](matrix.md)).\n\n### Limitations\n\nNot every token supported by `DateTime#toFormat` is supported in the parser. For example, there's no `ZZZZ` or `ZZZZZ` tokens. This is for a few reasons:\n\n- Luxon relies on natively-available functionality that only provides the mapping in one direction. We can ask what the named offset is and get \"Eastern Standard Time\" but not ask what \"Eastern Standard Time\" is most likely to mean.\n- Some things are ambiguous. There are several Eastern Standard Times in different countries and Luxon has no way to know which one you mean without additional information (such as that the zone is America/New_York) that would make EST superfluous anyway. Similarly, the single-letter month and weekday formats (EEEEE) that are useful in displaying calendars graphically can't be parsed because of their ambiguity.\n- Because of the limitations above, Luxon also doesn't support the \"macro\" tokens that include offset names, such as \"ttt\" and \"FFFF\".\n\n### Parsing Two Digit Years\n\nIn order to parse a two digit string as a year (or ISO week year), the `yy` (and `kk`) token must use a cutoff year after which the year being parsed is interpreted as referring to the current century. By default, the cutoff year is set to 60, meaning that the string \"60\" is parsed as the year 2060, and the string \"61\" is parsed as the year 1961. The cutoff year can be configured using `Settings.twoDigitCutoffYear`.\n\n### Debugging\n\nThere are two kinds of things that can go wrong when parsing a string: a) you make a mistake with the tokens or b) the information parsed from the string does not correspond to a valid date. To help you sort that out, Luxon provides a method called `fromFormatExplain`. It takes the same arguments as `fromFormat` but returns a map of information about the parse that can be useful in debugging.\n\nFor example, here the code is using \"MMMM\" where \"MMM\" was needed. You can see the regex Luxon uses and see that it didn't match anything:\n\n```js\n> DateTime.fromFormatExplain(\"Aug 6 1982\", \"MMMM d yyyy\")\n\n{ input: 'Aug 6 1982',\n tokens:\n [ { literal: false, val: 'MMMM' },\n { literal: false, val: ' ' },\n { literal: false, val: 'd' },\n { literal: false, val: ' ' },\n { literal: false, val: 'yyyy' } ],\n regex: '(January|February|March|April|May|June|July|August|September|October|November|December)( )(\\\\d\\\\d?)( )(\\\\d{4})',\n matches: {},\n result: {},\n zone: null }\n```\n\nIf you parse something and get an invalid date, the debugging steps are slightly different. Here, we're attempting to parse August 32nd, which doesn't exist:\n\n```js\nvar d = DateTime.fromFormat(\"August 32 1982\", \"MMMM d yyyy\");\nd.isValid; //=> false\nd.invalidReason; //=> 'day out of range'\n```\n\nFor more on validity and how to debug it, see [validity](validity.md). You may find more comprehensive tips there. But as it applies specifically to `fromFormat`, again try `fromFormatExplain`:\n\n```js\n> DateTime.fromFormatExplain(\"August 32 1982\", \"MMMM d yyyy\")\n\n{ input: 'August 32 1982',\n tokens:\n [ { literal: false, val: 'MMMM' },\n { literal: false, val: ' ' },\n { literal: false, val: 'd' },\n { literal: false, val: ' ' },\n { literal: false, val: 'yyyy' } ],\n regex: '(January|February|March|April|May|June|July|August|September|October|November|December)( )(\\\\d\\\\d?)( )(\\\\d{4})',\n matches: { M: 8, d: 32, y: 1982 },\n result: { month: 8, day: 32, year: 1982 },\n zone: null }\n```\n\nBecause Luxon was able to parse the string without difficulty, the output is a lot richer. And you can see that the \"day\" field is set to 32. Combined with the \"out of range\" explanation above, that should clear up the situation.\n\n### Table of tokens\n\n(Examples below given for `2014-08-06T13:07:04.054` considered as a local time in America/New_York). Note that many tokens supported by the [formatter](formatting.md) are **not** supported by the parser.\n\n| Standalone token | Format token | Description | Example |\n| ---------------- | ------------ | ----------------------------------------------------------------- | --------------------------- |\n| S | | millisecond, no padding | `54` |\n| SSS | | millisecond, padded to 3 | `054` |\n| u | | fractional seconds, (5 is a half second, 54 is slightly more) | `54` |\n| uu | | fractional seconds, (one or two digits) | `05` |\n| uuu | | fractional seconds, (only one digit) | `5` |\n| s | | second, no padding | `4` |\n| ss | | second, padded to 2 padding | `04` |\n| m | | minute, no padding | `7` |\n| mm | | minute, padded to 2 | `07` |\n| h | | hour in 12-hour time, no padding | `1` |\n| hh | | hour in 12-hour time, padded to 2 | `01` |\n| H | | hour in 24-hour time, no padding | `13` |\n| HH | | hour in 24-hour time, padded to 2 | `13` |\n| Z | | narrow offset | `+5` |\n| ZZ | | short offset | `+05:00` |\n| ZZZ | | techie offset | `+0500` |\n| z | | IANA zone | `America/New_York` |\n| a | | meridiem | `AM` |\n| d | | day of the month, no padding | `6` |\n| dd | | day of the month, padded to 2 | `06` |\n| E | c | day of the week, as number from 1-7 (Monday is 1, Sunday is 7) | `3` |\n| EEE | ccc | day of the week, as an abbreviate localized string | `Wed` |\n| EEEE | cccc | day of the week, as an unabbreviated localized string | `Wednesday` |\n| M | L | month as an unpadded number | `8` |\n| MM | LL | month as an padded number | `08` |\n| MMM | LLL | month as an abbreviated localized string | `Aug` |\n| MMMM | LLLL | month as an unabbreviated localized string | `August` |\n| y | | year, 1-6 digits, very literally | `2014` |\n| yy | | two-digit year, interpreted as > 1960 by default (also accepts 4) | `14` |\n| yyyy | | four-digit year | `2014` |\n| yyyyy | | four- to six-digit years | `10340` |\n| yyyyyy | | six-digit years | `010340` |\n| G | | abbreviated localized era | `AD` |\n| GG | | unabbreviated localized era | `Anno Domini` |\n| GGGGG | | one-letter localized era | `A` |\n| kk | | ISO week year, unpadded | `17` |\n| kkkk | | ISO week year, padded to 4 | `2014` |\n| W | | ISO week number, unpadded | `32` |\n| WW | | ISO week number, padded to 2 | `32` |\n| o | | ordinal (day of year), unpadded | `218` |\n| ooo | | ordinal (day of year), padded to 3 | `218` |\n| q | | quarter, no padding | `3` |\n| D | | localized numeric date | `9/6/2014` |\n| DD | | localized date with abbreviated month | `Aug 6, 2014` |\n| DDD | | localized date with full month | `August 6, 2014` |\n| DDDD | | localized date with full month and weekday | `Wednesday, August 6, 2014` |\n| t | | localized time | `1:07 AM` |\n| tt | | localized time with seconds | `1:07:04 PM` |\n| T | | localized 24-hour time | `13:07` |\n| TT | | localized 24-hour time with seconds | `13:07:04` |\n| f | | short localized date and time | `8/6/2014, 1:07 PM` |\n| ff | | less short localized date and time | `Aug 6, 2014, 1:07 PM` |\n| F | | short localized date and time with seconds | `8/6/2014, 1:07:04 PM` |\n| FF | | less short localized date and time with seconds | `Aug 6, 2014, 1:07:04 PM` |\n| ' | | literal start/end, characters between are not tokenized | `'T'` |\n"
},
{
"path": "docs/tour.md",
"content": "# A quick tour\n\nLuxon is a library that makes it easier to work with dates and times in JavaScript. If you want, add and subtract them, format and parse them, ask them hard questions, and so on, Luxon provides a much easier and comprehensive interface than the native types it wraps. We're going to talk about the most immediately useful subset of that interface.\n\nThis is going to be a bit brisk, but keep in mind that the API docs are comprehensive, so if you want to know more, feel free to [dive into them](https://moment.github.io/luxon/api-docs/index.html).\n\n## Your first DateTime\n\nThe most important class in Luxon is `DateTime`. A DateTime represents a specific millisecond in time, along with a time zone and a locale. Here's one that represents May 15, 2017 at 8:30 in the morning:\n\n```js\nconst dt = DateTime.local(2017, 5, 15, 8, 30);\n```\n\n[DateTime.local](../class/src/datetime.js~DateTime.html#static-method-local) takes any number of arguments, all the way out to milliseconds (months are 1-indexed). Underneath, this is similar to a JavaScript Date object. But we've decorated it with lots of useful methods.\n\n## Creating a DateTime\n\nThere are lots of ways to create a DateTime by parsing strings or constructing them out of parts. You've already seen one, `DateTime.local()`, but let's talk about three more.\n\n### Get the current date and time\n\nTo get the current time, just do this:\n\n```js\nconst now = DateTime.now();\n```\n\nThis is really the equivalent to calling `DateTime.local()` with no arguments, but it's a little clearer.\n\n### Create from an object\n\nThe most powerful way to create a DateTime instance is to provide an object containing all the information:\n\n```js\ndt = DateTime.fromObject({day: 22, hour: 12 }, { zone: 'America/Los_Angeles', numberingSystem: 'beng'})\n```\n\nDon't worry too much about the properties you don't understand yet; the point is that you can set every attribute of a DateTime when you create it. One thing to notice from the example is that we just set the day and hour; the year and month get defaulted to the current one and the minutes, seconds, and milliseconds get defaulted to 0. So `DateTime.fromObject` is sort of the power user interface.\n\n### Parse from ISO 8601\n\nLuxon has lots of parsing capabilities, but the most important one is parsing [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601) strings, because they're more-or-less the standard wire format for dates and times. Use `DateTime.fromISO`.\n\n\n```js\nDateTime.fromISO(\"2017-05-15\") //=> May 15, 2017 at midnight\nDateTime.fromISO(\"2017-05-15T08:30:00\") //=> May 15, 2017 at 8:30\n```\n\nYou can parse a bunch of other formats, including [your own custom ones](parsing.md).\n\n## Getting to know your DateTime instance\n\nNow that we've made some DateTimes, let's see what we can ask of it.\n\n### toString\n\nThe first thing we want to see is the DateTime as a string. Luxon returns ISO 8601 strings:\n\n```js\nDateTime.now().toString(); //=> '2017-09-14T03:20:34.091-04:00'\n```\n\n### Getting at components\n\nWe can get at the components of the time individually through getters. For example:\n\n```js\ndt = DateTime.now();\ndt.year //=> 2017\ndt.month //=> 9\ndt.day //=> 14\ndt.second //=> 47\ndt.weekday //=> 4\n```\n\n### Other fun accessors\n\n```js\ndt.zoneName //=> 'America/New_York'\ndt.offset //=> -240\ndt.daysInMonth //=> 30\n```\n\nThere are lots more!\n\n## Formatting your DateTime\n\nYou may want to output your DateTime to a string for a machine or a human to read. Luxon has lots of tools for this, but two of them are most important. If you want to format a human-readable string, use `toLocaleString`:\n\n```js\ndt.toLocaleString() //=> '9/14/2017'\ndt.toLocaleString(DateTime.DATETIME_MED) //=> 'September 14, 3:21 AM'\n```\n\nThis works well across different locales (languages) by letting the browser figure out what order the different parts go in and how to punctuate them.\n\nIf you want the string read by another program, you almost certainly want to use `toISO`:\n\n```js\ndt.toISO() //=> '2017-09-14T03:21:47.070-04:00'\n```\n\nCustom formats are also supported. See [formatting](formatting).\n\n## Transforming your DateTime\n\n### Immutability\n\nLuxon objects are immutable. That means that you can't alter them in place, just create altered copies. Throughout the documentation, we use terms like \"alter\", \"change\", and \"set\" loosely, but rest assured we mean \"create a new instance with different properties\".\n\n### Math\n\nThis is easier to show than to tell. All of these calls return new DateTime instances:\n\n```js\nvar dt = DateTime.now();\ndt.plus({ hours: 3, minutes: 2 });\ndt.minus({ days: 7 });\ndt.startOf('day');\ndt.endOf('hour');\n```\n\n### Set\n\nYou can create new instances by overriding specific properties:\n\n```js\nvar dt = DateTime.now();\ndt.set({hour: 3}).hour //=> 3\n```\n\n## Intl\n\nLuxon provides several different Intl capabilities, but the most important one is in formatting:\n\n```js\nvar dt = DateTime.now();\nvar f = {month: 'long', day: 'numeric'};\ndt.setLocale('fr').toLocaleString(f) //=> '14 septembre'\ndt.setLocale('en-GB').toLocaleString(f) //=> '14 September'\ndt.setLocale('en-US').toLocaleString(f) //=> 'September 14'\n```\n\nLuxon's Info class can also list months or weekdays for different locales:\n\n```js\nInfo.months('long', {locale: 'fr'}) //=> [ 'janvier', 'février', 'mars', 'avril', ... ]\n```\n\n## Time zones\n\nLuxon supports time zones. There's a whole [big section](zones) about it. But briefly, you can create DateTimes in specific zones and change their zones:\n\n```js\nDateTime.fromObject({}, {zone: 'America/Los_Angeles'}); // now, but expressed in LA's local time\nDateTime.now().setZone(\"America/Los_Angeles\"); // same\n```\n\nLuxon also supports UTC directly:\n\n```js\nDateTime.utc(2017, 5, 15);\nDateTime.utc(); // now, in UTC time zone\nDateTime.now().toUTC();\nDateTime.utc().toLocal();\n```\n\n## Durations\n\nThe Duration class represents a quantity of time such as \"2 hours and 7 minutes\". You create them like this:\n\n```js\nvar dur = Duration.fromObject({ hours: 2, minutes: 7 });\n```\n\nThey can be added or subtracted from DateTimes like this:\n\n```js\ndt.plus(dur);\n```\n\nThey have getters just like DateTime:\n\n```js\ndur.hours //=> 2\ndur.minutes //=> 7\ndur.seconds //=> 0\n```\n\nAnd some other useful stuff:\n\n```js\ndur.as('seconds') //=> 7620\ndur.toObject() //=> { hours: 2, minutes: 7 }\ndur.toISO() //=> 'PT2H7M'\n```\n\nYou can also format, negate, and normalize them. See it all in the `Duration` API docs.\n\n## Intervals\n\nIntervals are a specific period of time, such as \"between now and midnight\". They're really a wrapper for two DateTimes that form its endpoints. Here's what you can do with them:\n\n```js\nnow = DateTime.now();\nlater = DateTime.local(2020, 10, 12);\ni = Interval.fromDateTimes(now, later);\n\ni.length() //=> 97098768468\ni.length('years') //=> 3.0762420239726027\ni.contains(DateTime.local(2019)) //=> true\n\ni.toISO() //=> '2017-09-14T04:07:11.532-04:00/2020-10-12T00:00:00.000-04:00'\ni.toString() //=> '[2017-09-14T04:07:11.532-04:00 – 2020-10-12T00:00:00.000-04:00)\n```\n\nNote that Luxon's Intervals are always half-open, meaning the starting point is included in the interval while the end point is not.\nThe following code will not work as expected:\n```js\nconst start = DateTime.now().startOf('day');\nconst end = start.endOf('day');\nconst i = Interval.fromDateTimes(start, end);\n\ni.length('hours') //=> 23.99999972222222\ni.toString() //=> [2025-07-09T00:00:00.000+02:00 – 2025-07-09T23:59:59.999+02:00)\n```\n\nThis is because `endOf('day')` returns the last millisecond of the day and as a result that last millisecond is _not_\nincluded in the interval.\n\n`Interval.after` or `Interval.before` are better suited for creating Intervals of a specific length:\n```js\nconst start = DateTime.now().startOf('day');\nconst i1 = Interval.after(start, { days: 1 });\nconst i2 = Interval.before(start, { days: 1 });\n\ni1.length('hours') //=> 24\ni1.toString() //=> [2025-07-09T00:00:00.000+02:00 – 2025-07-10T00:00:00.000+02:00)\n\ni2.length('hours') //=> 24\ni2.toString() //=> [2025-07-08T00:00:00.000+02:00 – 2025-07-09T00:00:00.000+02:00)\n```\n\nIntervals can be split up into smaller intervals, perform set-like operations with other intervals, and few other handy features. See the `Interval` API docs.\n"
},
{
"path": "docs/upgrading.md",
"content": "# Upgrading Luxon\n\n## 2.x to 3.0\n\nVersion 3.0 has one breaking change: specifying \"system\" as the zone always results in the system zone, regardless of what you have the default set to. To get the default zone (whatever it is set to), use \"default\":\n\n```js\nSettings.defaultZone = \"America/Chicago\";\n\nDateTime.now().setZone(\"default\") // results in Chicago time\nDateTime.now().setZone(\"system\") // uses the user's system time\n```\n\nIf this seems obvious, just be aware that it didn't work like that before!\n\n## 1.x to 2.0\n\nVersion 2.0 of Luxon has a number of breaking changes.\n\n### Environment support\n\nLuxon 2.0 does not support Node < 12, or any version of IE. It also only supports newer versions of major browsers. This change\nallows Luxon to make more assumptions about what's supported in the environment and will allow Luxon's code to simplify. See\nthe [Support Matrix](matrix.md) for more.\n\nFor this same reason, a polyfilled build is no longer provided; everything Luxon needs comes standard on browsers.\n\n### Breaking signature changes\n\nThere are many more specific breaking changes. Most are aimed and making Luxon's handling of option parameters more consistent.\n\n#### fromObject\n`DateTime.fromObject()` and `Duration.fromObject()` now accept two parameters: one for the object and one for the options.\n\nFor example:\n\n```js\n// Luxon 1.x\nDateTime.fromObject({ hour: 3, minute: 2, zone: \"America/New_York\", locale: \"ru\" });\nDuration.fromObject({ hours: 3, minutes: 2, conversionAccuracy: \"casual\", locale: \"ru\" });\n\n// vs Luxon 2.x\nDateTime.fromObject({ hour: 3, minute: 2 }, { zone: \"America/New_York\", locale: \"ru\" });\nDuration.fromObject({ hours: 3, minutes: 2 }, { conversionAccuracy: \"casual\", locale: \"ru\" });\n```\n\n#### toLocaleString\n\nIn Luxon 1.x, you can mix Intl options with overrides of the DateTime configuration into the same options parameter. These are now\ntwo separate parameters:\n\n```js\n\n// Luxon 1.x\nDateTime.now().toLocaleString({ hour: \"2-digit\", locale: \"ru\" })\n\n// vs Luxon 2.x\n\nDateTime.now().toLocaleString({ hour: \"2-digit\" }, { locale: \"ru\" })\n```\n\n#### System zone\n\nThe zone of the executing environment (e.g. the time set on the computer running the browser running Luxon), is now called\n\"system\" instead of \"local\" to reduce confusion.\n\n```js\nDateTime.fromObject({}, { zone: \"local\" }) // still works\nDateTime.fromObject({}, { zone: \"system\" }) // preferred\n\nDateTime.fromObject({}, { zone: \"system\" }).zone // => type is SystemZone\nDateTime.fromObject({}, { zone: \"system\" }).zone.type // => \"system\"\n```\n\n#### Default zone\n\nLuxon 2.x cleans up the handling of `Settings.defaultZone`:\n\n```js\n\n// setting\nSettings.defaultZone = \"America/New_York\"; // can take a string\nSettings.defaultZone = IANAZone.create(\"America/New_York\"); // or a Zone instance\n\n// getting\nSettings.defaultZone //=> a Zone instance\n```\n\nThe most significant breaking change here is that `Settings.defaultZoneName` no longer exists.\n\n#### Other breaking changes\n\n * `DateTime#toObject` no longer accepts an `includeConfig` option\n * `resolvedLocaleOpts` is now `resolvedLocaleOptions`\n * `Zone#universal` is now `Zone#isUniversal`\n\n### Non-breaking changes\n\n * `DateTime.local()` and `DateTime.utc()` now take an options parameter for setting zone and locale, same as `fromObject()`.\n\n### A note\n\nWe originally had more ambitious plans for Luxon 2.0: a port to Typescript, an overhaul of error handling, and lots of other changes.\nThe problem is that we're very busy, and in the meantime browsers have evolved quickly, the mistakes in our API bothered a lot\nof developers, and our need to support old environments made Luxon more difficult to change. So we made a basic set of changes\nto give us some operating room. And hopefully someday we'll get back to those more ambitious plans.\n"
},
{
"path": "docs/validity.md",
"content": "# Validity\n\n## Invalid DateTimes\n\nOne of the most irritating aspects of programming with time is that it's possible to end up with invalid dates. This is a bit subtle: barring integer overflows, there's no count of milliseconds that don't correspond to a valid DateTime, but when working with calendar units, it's pretty easy to say something like \"June 400th\". Luxon considers that invalid and will mark it accordingly.\n\nUnless you've asked Luxon to throw an exception when it creates an invalid DateTime (see more on that below), it will fail silently, creating an instance that doesn't know how to do anything. You can check validity with `isValid`:\n\n```js\n> var dt = DateTime.fromObject({ month: 6, day: 400 });\ndt.isValid //=> false\n```\n\nAll of the methods or getters that return primitives return degenerate ones:\n\n```js\ndt.year; //=> NaN\ndt.toString(); //=> 'Invalid DateTime'\ndt.toObject(); //=> {}\n```\n\nMethods that return other Luxon objects will return invalid ones:\n\n```js\ndt.plus({ days: 4 }).isValid; //=> false\n```\n\n## Reasons a DateTimes can be invalid\n\nThe most common way to do that is to over- or underflow some unit:\n\n- February 40th\n- 28:00\n- -4 pm\n- etc\n\nBut there are other ways to do it:\n\n```js\n// specify a time zone that doesn't exist\nDateTime.now().setZone(\"America/Blorp\").isValid; //=> false\n\n// provide contradictory information (here, this date is not a Wednesday)\nDateTime.fromObject({ year: 2017, month: 5, day: 25, weekday: 3 }).isValid; //=> false\n```\n\nNote that some other kinds of mistakes throw, based on our judgment that they are more likely programmer errors than data issues:\n\n```js\nDateTime.now().set({ blorp: 7 }); //=> kerplosion\n```\n\n## Debugging invalid DateTimes\n\nBecause DateTimes fail silently, they can be a pain to debug. Luxon has some features that can help.\n\n### invalidReason and invalidExplanation\n\nInvalid DateTime objects are happy to tell you why they're invalid. `invalidReason` will give you a consistent error code you can use, whereas `invalidExplanation` will spell it out\n\n```js\nvar dt = DateTime.now().setZone(\"America/Blorp\");\ndt.invalidReason; //=> 'unsupported zone'\ndt.invalidExplanation; //=> 'the zone \"America/Blorp\" is not supported'\n```\n\n### throwOnInvalid\n\nYou can make Luxon throw whenever it creates an invalid DateTime. The message will combine `invalidReason` and `invalidExplanation`:\n\n```js\nSettings.throwOnInvalid = true;\nDateTime.now().setZone(\"America/Blorp\"); //=> Error: Invalid DateTime: unsupported zone: the zone \"America/Blorp\" is not supported\n```\n\nYou can of course leave this on in production too, but be sure to try/catch it appropriately.\n\n## Invalid Durations\n\nDurations can be invalid too. The easiest way to get one is to diff an invalid DateTime.\n\n```js\nDateTime.local(2017, 28).diffNow().isValid; //=> false\n```\n\n## Invalid Intervals\n\nIntervals can be invalid. This can happen a few different ways:\n\n- The end time is before the start time\n- It was created from invalid DateTime or Duration\n"
},
{
"path": "docs/why.md",
"content": "# Why does Luxon exist?\n\nWhat's the deal with this whole Luxon thing anyway? Why did I write it? How is it related to the Moment project? What's different about it? This page tries to hash all that out.\n\n## A disclaimer\n\nI should clarify here that I'm just one of Moment's maintainers; I'm not in charge and I'm not Moment's creator. The opinions here are solely mine. Finally, none of this is meant to bash Moment, a project I've spent a lot of time on and whose other developers I respect.\n\n## Origin\n\nLuxon started because I had a bunch of ideas on how to improve Moment but kept finding Moment wasn't a good codebase to explore them with. Namely:\n\n- I wanted to try out some ideas that I thought would provide a better, more explicit API but didn't want to break everything in Moment.\n- I had an idea on how to provide out-of-the-box, no-data-files-required support for time zones, but Moment's design made that difficult.\n- I wanted to completely rethink how internationalization worked by using the Intl API that comes packaged in browsers.\n- I wanted to use a modern JS toolchain, which would require a major retrofit to Moment.\n\nSo I decided to write something from scratch, a sort of modernized Moment. It's a combination of all the things I learned maintaining Moment and Twix, plus a bunch of fresh ideas. I worked on it in little slivers of spare time for about two years. But now it's ready to actually use, and the Moment team likes it enough that we pulled it under the organization's umbrella.\n\n## Ideas in Luxon\n\nLuxon is built around a few core ideas:\n\n1. Keep the basic chainable date wrapper idea from Moment.\n1. Make all the types immutable.\n1. Make the API explicit; different methods do different things and have well-defined options.\n1. Use the Intl API to provide internationalization, including token parsing. Fall back to English if the browser doesn't support those APIs.\n1. Abuse the Intl API horribly to provide time zone support. Only possible for modern browsers.\n1. Provide more comprehensive duration support.\n1. Directly provide interval support.\n1. Write inline docs for everything.\n\nThese ideas have some big advantages:\n\n1. It's much easier to understand and debug code that uses Luxon.\n1. Using native browser capabilities for internationalization leads to a much better behavior and is dramatically easier to maintain.\n1. Luxon has the best time zone support of any JS date library.\n1. Luxon's durations are both flexible and easy to use.\n1. The documentation is very good.\n\nThey also have some disadvantages:\n\n1. Using modern browser capabilities means that the fallback behavior introduces complexity for the programmer.\n1. Never keeping internationalized strings in the code base means that some capabilities have to wait until the browsers provide it.\n1. Some aspects of the Intl API are browser-dependent, which means Luxon's behavior is too.\n\n## Place in the Moment project\n\nLuxon lives in the Moment project because, basically, we all really like it, and it represents a huge improvement.\n\nBut Luxon doesn't quite fulfill Moment's mandate. Since it sometimes relies on browsers' implementations of the `Intl` specifications, it doesn't provide some of Moment's most commonly-used features on all browsers. Relative date formatting is for instance not supported in IE11 and [other older browsers](https://caniuse.com/?search=Intl%20RelativeTimeFormat). Luxon's Intl features do not work as expected on sufficiently outdated browsers, whereas Moment's all work everywhere. That represents a good tradeoff, IMO, but it's clearly a different one than Moment makes.\n\nLuxon makes a major break in API conventions. Part of Moment's charm is that you just call `moment()` on basically anything and you get date, whereas Luxon forces you to decide that you want to call `fromISO` or whatever. The upshot of all that is that Luxon feels like a different library; that's why it's not Moment 3.0.\n\nSo what is it then? We're not really sure. We're calling it a Moment labs project. Will its ideas get backported into Moment 3? Will it gradually siphon users away from Moment and become the focus of the Moment project? Will the march of modern browsers retire the arguments above and cause us to revisit branding Luxon as Moment? We don't know.\n\nThere, now you know as much as I do.\n\n## Future plans\n\nLuxon is fully usable and I plan to support it indefinitely. It's also largely complete. Luxon will eventually strip out its fallbacks for missing platform features. But overall I expect the core functionality to stay basically as it is, adding mostly minor tweaks and bugfixes.\n"
},
{
"path": "docs/zones.md",
"content": "# Time zones and offsets\n\nLuxon has support for time zones. This page explains how to use them.\n\n## Don't worry!\n\nYou _usually_ don't need to worry about time zones. Your code runs on a computer with a particular time zone and everything will work consistently in that zone without you doing anything. It's when you want to do complicated stuff _across_ zones that you have to think about it. Even then, here are some pointers to help you avoid situations where you have to think carefully about time zones:\n\n1. Don't make servers think about _local_ times. Configure them to use UTC and write your server's code to work in UTC. Times can often be thought of as a simple count of epoch milliseconds; what you would call that time (e.g. 9:30) in what zone doesn't (again, often) matter.\n2. Communicate times between systems in ISO 8601, like `2017-05-15T13:30:34Z` where possible (it doesn't matter if you use Z or some local offset; the point is that it precisely identifies the millisecond on the global timeline).\n3. Where possible, only think of time zones as a formatting concern; your application ideally never knows that the time it's working with is called \"9:00\" until it's being rendered to the user.\n4. Barring 3, do as much manipulation of the time (say, adding an hour to the current time) in the client code that's already running in the time zone where the results will matter.\n\nAll those things will make it less likely you ever need to work explicitly with time zones and may also save you plenty of other headaches. But those aren't possible for some applications; you might need to work with times in zones other than the one the program is running in, for any number of reasons. And that's where Luxon's time zone support comes in.\n\n## Terminology\n\nBear with me here. Time zones are a pain in the ass. Luxon has lots of tools to deal with them, but there's no getting around the fact that they're complicated. The terminology for time zones and offsets isn't well-established. But let's try to impose some order:\n\n1. An **offset** is a difference between the local time and the UTC time, such as +5 (hours) or -12:30. They may be expressed directly in minutes, or in hours, or in a combination of minutes and hours. Here we'll use hours.\n1. A **time zone** is a set of rules, associated with a geographical location, that determines the local offset from UTC at any given time. The best way to identify a zone is by its IANA string, such as \"America/New_York\". That zone says something to the effect of \"The offset is -5, except between March and November, when it's -4\".\n1. A **fixed-offset time zone** is any time zone that never changes offsets, such as UTC. Luxon supports fixed-offset zones directly; they're specified like UTC+7, which you can interpret as \"always with an offset of +7\".\n1. A **named offset** is a time zone-specific name for an offset, such as Eastern Daylight Time. It expresses both the zone (America's EST roughly implies America/New_York) and the current offset (EST means -5). They are also confusing in that they overspecify the offset (e.g. for any given time it is unnecessary to specify EST vs EDT; it's always whichever one is right). They are also ambiguous (BST is both British Summer Time and Bangladesh Standard Time), unstandardized, and internationalized (what would a Frenchman call the US's EST?). For all these reasons, you should avoid them when specifying times programmatically. Luxon only supports their use in formatting.\n\nSome subtleties:\n\n1. Multiple zones can have the same offset (think about the US's zones and their Canadian equivalents), though they might not have the same offset all the time, depending on when their DSTs are. Thus zones and offsets have a many-to-many relationship.\n1. Just because a time zone doesn't have a DST now doesn't mean it's fixed. Perhaps it had one in the past. Regardless, Luxon does not have first-class access to the list of rules, so it assumes any IANA-specified zone is not fixed and checks for its current offset programmatically.\n\nIf all this seems too terse, check out these articles. The terminology in them is subtly different but the concepts are the same:\n\n- [Time Zones Aren’t Offsets – Offsets Aren’t Time Zones](https://spin.atomicobject.com/2016/07/06/time-zones-offsets/)\n- [Stack Overflow's timezone wiki page](https://stackoverflow.com/tags/timezone/info)\n\n## Luxon works with time zones\n\nLuxon's DateTime class supports zones directly. By default, a date created in Luxon is \"in\" the local time zone of the machine it's running on. By \"in\" we mean that the DateTime has, as one of its properties, an associated zone.\n\nIt's important to remember that a DateTime represents a specific instant in time and that instant has an unambiguous meaning independent of what time zone you're in; the zone is really a piece of social metadata that affects how humans interact with the time, rather than a fact about the passing of time itself. Of course, Luxon is a library for humans, so that social metadata affects Luxon's behavior too. It just doesn't change _what time it is_.\n\nSpecifically, a DateTime's zone affects its behavior in these ways:\n\n1. Times will be formatted as they would be in that zone.\n1. Transformations to the DateTime (such as `plus` or `startOf`) will obey any DSTs in that zone that affect the calculation (see \"Math across DSTs\" below)\n\nGenerally speaking, Luxon does not support changing a DateTime's offset, just its zone. That allows it to enforce the behaviors in the list above. The offset for that DateTime is just whatever the zone says it is. If you are unconcerned with the effects above, then you can always give your DateTime a fixed-offset zone.\n\n## Specifying a zone\n\nLuxon's API methods that take a zone as an argument all let you specify the zone in a few ways.\n\n| Type | Example | Description |\n| ------------ | ------------------ | ----------------------------------------------------------------- |\n| IANA | 'America/New_York' | that zone |\n| system | 'system' | the system's local zone |\n| default | 'default' | the default zone set by Settings.defaultZone |\n| UTC | 'utc' | Universal Coordinated Time |\n| fixed offset | 'UTC+7' | a fixed offset zone |\n| Zone | new YourZone() | A custom implementation of Luxon's Zone interface (advanced only) |\n\n### IANA support\n\nIANA-specified zones are string identifiers like \"America/New_York\" or \"Asia/Tokyo\". Luxon gains direct support for them by abusing built-in Intl APIs.\n\nIf you specify a zone and your environment doesn't support that zone, you'll get an [invalid](validity.md) DateTime. That could be because the environment doesn't support zones at all (generally browsers older than Luxon supports), because for whatever reason it doesn't support that _particular_ zone, or because the zone is just bogus. Like this:\n\n```js\nbogus = DateTime.local().setZone(\"America/Bogus\");\n\nbogus.isValid; //=> false\nbogus.invalidReason; //=> 'unsupported zone'\n```\n\n## Creating DateTimes\n\n### System zone by default\n\nBy default, DateTime instances are created in the system's local zone and parsed strings are interpreted as specifying times in the system's zone. For example, my computer is configured to use `America/New_York`, which has an offset of -4 in May:\n\n```js\nvar local = DateTime.local(2017, 05, 15, 9, 10, 23);\n\nlocal.zoneName; //=> 'America/New_York'\nlocal.toString(); //=> '2017-05-15T09:10:23.000-04:00'\n\nvar iso = DateTime.fromISO(\"2017-05-15T09:10:23\");\n\niso.zoneName; //=> 'America/New_York'\niso.toString(); //=> '2017-05-15T09:10:23.000-04:00'\n```\n\n### Creating DateTimes in a zone\n\nMany of Luxon's factory methods allow you to tell it specifically what zone to create the DateTime in:\n\n```js\nvar overrideZone = DateTime.fromISO(\"2017-05-15T09:10:23\", { zone: \"Europe/Paris\" });\n\noverrideZone.zoneName; //=> 'Europe/Paris'\noverrideZone.toString(); //=> '2017-05-15T09:10:23.000+02:00'\n```\n\nNote two things:\n\n1. The date and time specified in the string was interpreted as a Parisian local time (i.e. it's the time that corresponds to what would be called 9:10 _there_).\n2. The resulting DateTime object is in Europe/Paris.\n\nThose are conceptually independent (i.e. Luxon could have converted the time to the system zone), but in practice it's more convenient for the same option to govern both.\n\nIn addition, one static method, `utc()`, specifically interprets the input as being specified in UTC. It also returns a DateTime in UTC:\n\n```js\nvar utc = DateTime.utc(2017, 05, 15, 9, 10, 23);\n\nutc.zoneName; //=> 'UTC'\nutc.toString(); //=> '2017-05-15T09:10:23.000Z'\n```\n\n### Strings that specify an offset\n\nSome input strings may specify an offset as part of the string itself. In these cases, Luxon interprets the time as being specified with that offset, but converts the resulting DateTime into the system's local zone:\n\n```js\nvar specifyOffset = DateTime.fromISO(\"2017-05-15T09:10:23-09:00\");\n\nspecifyOffset.zoneName; //=> 'America/New_York'\nspecifyOffset.toString(); //=> '2017-05-15T14:10:23.000-04:00'\n\nvar specifyZone = DateTime.fromFormat(\n \"2017-05-15T09:10:23 Europe/Paris\",\n \"yyyy-MM-dd'T'HH:mm:ss z\"\n);\n\nspecifyZone.zoneName; //=> 'America/New_York'\nspecifyZone.toString(); //=> '2017-05-15T03:10:23.000-04:00'\n```\n\n...unless a zone is specified as an option (see previous section), in which case the DateTime gets converted to _that_ zone:\n\n```js\nvar specifyOffsetAndOverrideZone = DateTime.fromISO(\"2017-05-15T09:10:23-09:00\", {\n zone: \"Europe/Paris\"\n});\n\nspecifyOffsetAndOverrideZone.zoneName; //=> 'Europe/Paris'\nspecifyOffsetAndOverrideZone.toString(); //=> '2017-05-15T20:10:23.000+02:00'\n```\n\n### setZone\n\nFinally, some parsing functions allow you to \"keep\" the zone in the string as the DateTime's zone. Note that if only an offset is provided by the string, the zone will be a fixed-offset one, since Luxon doesn't know which zone is meant, even if you do.\n\n```js\nvar keepOffset = DateTime.fromISO(\"2017-05-15T09:10:23-09:00\", { setZone: true });\n\nkeepOffset.zoneName; //=> 'UTC-9'\nkeepOffset.toString(); //=> '2017-05-15T09:10:23.000-09:00'\n\nvar keepZone = DateTime.fromFormat(\"2017-05-15T09:10:23 Europe/Paris\", \"yyyy-MM-dd'T'HH:mm:ss z\", {\n setZone: true\n});\n\nkeepZone.zoneName; //=> 'Europe/Paris'\nkeepZone.toString(); //=> '2017-05-15T09:10:23.000+02:00'\n```\n\n## Changing zones\n\n### setZone\n\nLuxon objects are immutable, so when we say \"changing zones\" we really mean \"creating a new instance with a different zone\". Changing zone generally means \"change the zone in which this DateTime is expressed (and according to which rules it is manipulated), but don't change the underlying timestamp.\" For example:\n\n```js\nvar local = DateTime.local();\nvar rezoned = local.setZone(\"America/Los_Angeles\");\n\n// different local times with different offsets\nlocal.toString(); //=> '2017-09-13T18:30:51.141-04:00'\nrezoned.toString(); //=> '2017-09-13T15:30:51.141-07:00'\n\n// but actually the same time\nlocal.valueOf() === rezoned.valueOf(); //=> true\n```\n\n### keepLocalTime\n\nGenerally, it's best to think of the zone as a sort of metadata that you slide around independent of the underlying count of milliseconds. However, sometimes that's not what you want. Sometimes you want to change zones while keeping the local time fixed and instead altering the timestamp. Luxon supports this:\n\n```js\nvar local = DateTime.local();\nvar rezoned = local.setZone(\"America/Los_Angeles\", { keepLocalTime: true });\n\nlocal.toString(); //=> '2017-09-13T18:36:23.187-04:00'\nrezoned.toString(); //=> '2017-09-13T18:36:23.187-07:00'\n\nlocal.valueOf() === rezoned.valueOf(); //=> false\n```\n\nIf you find that confusing, I recommend just not using it. On the other hand, if you find yourself using this all the time, you are probably doing something wrong.\n\n## Accessors\n\nLuxon DateTimes have a few different accessors that let you find out about the zone and offset:\n\n```js\nvar dt = DateTime.local();\n\ndt.zoneName; //=> 'America/New_York'\ndt.offset; //=> -240\ndt.offsetNameShort; //=> 'EDT'\ndt.offsetNameLong; //=> 'Eastern Daylight Time'\ndt.isOffsetFixed; //=> false\ndt.isInDST; //=> true\n```\n\nThose are all documented in the [DateTime API docs](https://moment.github.io/luxon/api-docs/index.html#datetime).\n\n## DST weirdness\n\nBecause our ancestors were morons, they opted for a system wherein many governments shift around the local time twice a year for no good reason. And it's not like they do it in a neat, coordinated fashion. No, they do it whimsically, varying the shifts' timing from country to country (or region to region!) and from year to year. And of course, they do it the opposite way south of the Equator. This is all a tremendous waste of everyone's energy and, er, time, but it is how the world works and a date and time library has to deal with it.\n\nMost of the time, DST shifts will happen without you having to do anything about it and everything will just work. Luxon goes to some pains to make DSTs as unweird as possible. But there are exceptions. This section covers them.\n\n### Invalid times\n\nSome local times simply don't exist. The Spring Forward DST shift involves shifting the local time forward by (usually) one hour. In my zone, `America/New_York`, on March 12, 2017 the millisecond after `1:59:59.999` is `3:00:00.000`. Thus the times between `2:00:00.000` and `2:59:59.999`, inclusive, don't exist in that zone. But of course, nothing stops a user from constructing a DateTime out of that local time.\n\nIf you create such a DateTime from scratch, the missing time will be advanced by an hour:\n\n```js\nDateTime.local(2017, 3, 12, 2, 30).toString(); //=> '2017-03-12T03:30:00.000-04:00'\n```\n\nYou can also do date math that lands you in the middle of the shift. These also push forward:\n\n```js\nDateTime.local(2017, 3, 11, 2, 30)\n .plus({ days: 1 })\n .toString(); //=> '2017-03-12T03:30:00.000-04:00'\nDateTime.local(2017, 3, 13, 2, 30)\n .minus({ days: 1 })\n .toString(); //=> '2017-03-12T03:30:00.000-04:00'\n```\n\n### Ambiguous times\n\nHarder to handle are ambiguous times. During Fall Back, some local times happen twice. In my zone, `America/New_York`, on November 5, 2017 the millisecond after `1:59:59.999` became `1:00:00.000`. But of course there was already a 1:00 that day, one hour before this one. So if you create a DateTime with a local time of 1:30, which time do you mean? It's an important question, because they correspond to different moments in time.\n\nHowever, Luxon's behavior here is undefined. It makes no promises about which of the two possible timestamps the instance will represent. Currently, its specific behavior is like this:\n\n```js\nDateTime.local(2017, 11, 5, 1, 30).offset / 60; //=> -4\nDateTime.local(2017, 11, 4, 1, 30).plus({ days: 1 }).offset / 60; //=> -4\nDateTime.local(2017, 11, 6, 1, 30).minus({ days: 1 }).offset / 60; //=> -5\n```\n\nIn other words, sometimes it picks one and sometimes the other. Luxon doesn't guarantee the specific behavior above. That's just what it happens to do.\n\nIf you're curious, this lack of definition is because Luxon doesn't actually know that any particular DateTime is an ambiguous time. It doesn't know the time zones rules at all. It just knows the local time does not contradict the offset and leaves it at that. To find out the time is ambiguous and define exact rules for how to resolve it, Luxon would have to test nearby times to see if it can find duplicate local time, and it would have to do that on every creation of a DateTime, regardless of whether it was anywhere near a real DST shift. Because that's onerous, Luxon doesn't bother.\n\n### Math across DSTs\n\nThere's a whole [section](math.md) about date and time math, but it's worth highlighting one thing here: when Luxon does math across DSTs, it adjusts for them when working with higher-order, variable-length units like days, weeks, months, and years. When working with lower-order, exact units like hours, minutes, and seconds, it does not. For example, DSTs mean that days are not always the same length: one day a year is (usually) 23 hours long and another is 25 hours long. Luxon makes sure that adding days takes that into account. On the other hand, an hour is always 3,600,000 milliseconds.\n\nAn easy way to think of it is that if you add a day to a DateTime, you should always get the same time the next day, regardless of any intervening DSTs. On the other hand, adding 24 hours will result in DateTime that is 24 hours later, which may or may not be the same time the next day. In this example, my zone is `America/New_York`, which had a Spring Forward DST in the early hours of March 12.\n\n```js\nvar start = DateTime.local(2017, 3, 11, 10);\nstart.hour; //=> 10, just for comparison\nstart.plus({ days: 1 }).hour; //=> 10, stayed the same\nstart.plus({ hours: 24 }).hour; //=> 11, DST pushed forward an hour\n```\n\n## Changing the default zone\n\nBy default, Luxon creates DateTimes in the system's zone. However, you can override this behavior globally:\n\n```js\nSettings.defaultZone = \"Asia/Tokyo\";\nDateTime.local().zoneName; //=> 'Asia/Tokyo'\n\nSettings.defaultZone = \"utc\";\nDateTime.local().zoneName; //=> 'UTC'\n\n// you can reset by setting to 'system'\n\nSettings.defaultZone = \"system\";\nDateTime.local().zoneName; //=> 'America/New_York'\n```\n"
},
{
"path": "jest.config.js",
"content": "module.exports = {\n testEnvironment: \"node\",\n roots: [\"test\"],\n coverageDirectory: \"build/coverage\",\n collectCoverageFrom: [\"src/**/*.js\", \"!src/zone.js\"],\n transform: {\n \"^.+\\\\.js$\": \"babel-jest\",\n },\n};\n"
},
{
"path": "package.json",
"content": "{\n \"name\": \"luxon\",\n \"version\": \"3.7.2\",\n \"description\": \"Immutable date wrapper\",\n \"author\": \"Isaac Cambron\",\n \"keywords\": [\n \"date\",\n \"immutable\"\n ],\n \"repository\": \"https://github.com/moment/luxon\",\n \"exports\": {\n \".\": {\n \"import\": \"./build/es6/luxon.mjs\",\n \"require\": \"./build/node/luxon.js\"\n },\n \"./package.json\": \"./package.json\"\n },\n \"scripts\": {\n \"build\": \"babel-node tasks/buildAll.js\",\n \"build-node\": \"babel-node tasks/buildNode.js\",\n \"build-global\": \"babel-node tasks/buildGlobal.js\",\n \"jest\": \"jest\",\n \"test\": \"jest --coverage\",\n \"api-docs\": \"mkdir -p build && documentation build src/luxon.js -f html -o build/api-docs && sed -i.bak 's/<\\\\/body>/\n \n \n \n