moment / luxon

⏱ A library for working with dates and times in JS

Moment.js

A JavaScript date library for parsing, validating, manipulating, and formatting dates.

Project Status

Moment.js is a legacy project, now in maintenance mode. In most cases, you should choose a different library.

For more details and recommendations, please see Project Status in the docs.

Thank you.

Resources

• Documentation
• Changelog
• Stack Overflow

License

Moment.js is freely distributable under the terms of the MIT license.

luxon's Issues

Expose formatToParts

There are probably two features here:

1. A version of toLocaleString that returns parts. Maybe toLocaleParts. Underneath, it's just formatToParts.
2. A version of toFormat that returns parts, i.e. has a return format consistent with formatToParts

Remove "setters" in favor of doing everything through set()

Implement startOf() and endOf() for weeks

Which builds should be polyfilled?

One problem around here is that I have no idea how people build modern Javascript applications. Luxon uses a few things not available in IE. You can see them polyfilled here. Luxon's build toolchain can decide whether it wants to include that stuff or not on a per-target basis. It's fairly obvious that for the browser global build, I want that stuff in there, and for the ES6 build I don't. But what about the CJS and AMD builds? In particularly, the CJS one goes on NPM and gets consumed by other people's toolchains. Do consumers of that expect libraries like Luxon to have polyfilled themselves or would they rather the libraries be smaller and add their own fills where needed?

Basic documentation

Inline documentation todos:

• DateTime inline class description
• Interval inline class description
• Duration inline class description
• Settings inline class description
• Info inline class description

Needed long-form docs:

• Install
• Formatting
• Parsing
• Getting started
• Zones/Offsets
• Feature support matrix
• Intl
• Output calendar
• Validity
• Math

Infra needs:

• ESDoc organization of long-form docs

Improved error & invalid handling

• Handle unknown zones more gracefully
• Add invalid reason and an accessor for it
• Add global option for throw-on-invalid
• Add separate classes for different exceptions

IE 11 support

A bunch of the advanced features won't work with IE, but right now it doesn't work at all, and it should.

Add a default locale setting

Clarify DateTime.fromJSDate behavior

Currently, passing an invalid Date to DateTime.fromJSDate yields the current local DateTime:

var DateTime = require("luxon").DateTime;

// works as described:
var a = new DateTime.fromJSDate(new Date(1000000000000));
a  // { [Number: 1000000000000] ... }
a.isValid  // true

// works, but isn't documented:
var b = new DateTime.fromJSDate(1000000000000);
b  // { [Number: 1000000000000] ... }
b.isValid  // true

// works, but unexpectedly:
var c = new DateTime.fromJSDate("totally not a date");
c  // { [Number: 1508613504066] ... }
c.isValid  // true

Intuitively, I'd expect an invalid JS Date to yield an invalid Luxon DateTime. What's the intended behavior?

Environment for testing?

My platform (Mac OS X, node 7 and icu4c installed with brew) threw errors when running gulp test, probably due to missing or outdated icu-full (most failing tests were due to missing translations). I've since updated to node 8 and installed icu-full and now all the tests are passing. However, I'm wondering if this environment should be documented somewhere (e.g. contributing.md) or if the repo should contain a Dockerfile that contains all the necessary environment setup (including gulp-cli and a US timezone that would fix issue #52) and a script to run the ci/tests in the Docker environment.

I'd be happy to provide such a file if needed, maybe even change .travis.yml to use the Docker environment. Or to update the documentation if you don't like Docker.

Consider making no-polyfill builds?

I'm not really sure how to do this cleanly, but the polyfills I added to support IE 11 are like 6KB. Seems silly. Also, the polyfills are global, which might be annoying?

Add defaults for outputCalendar and numberingSystem

The Settings class allows you to set default values for time zone and locale. There should be analogous settings for outputCalendar and maybe numberingSystem. The tricky thing about numberingSystem is that the default is for it to float, since we don't want it to override the locale's choices unless the user has specified that. So the default is really null, which is a little awkward as a setting.

This isn't a high priority for me, so thumbs up this if its absence is a problem for you.

Add convenience getters for month and weekday names

These are analogous to offsetNameShort and offsetNameLong:

• dateTime.weekdayShort
• dateTime.weekdayLong
• dateTime.monthShort
• dateTime.monthLong

Why don't the map files work in the tests?

Remove `add(1, 'day')` and only support `add({days: 1})`

A basic website + pub script

zoneName needs localized

DateTime.local().zoneName is sort of a mess. It seems to serve two purposes: one as a debugging tool to check what zone you're in and another as a thing to display to users. It currently fails at both:

1. for the system-local zone, it returns the IANA string, so that fails for the first purpose
2. its value is not localized, so that fails for the second purpose

This needs reworked:

1. dt.zoneName should return something in the dt's locale. Should be a convenience wrapper for dt.zone.readableName or somesuch.
2. dt.zone.name should return strings like 'local', etc; things that when fed back in as a zone specifier result in the right zone

Make sure long-term-accurate conversions are always available

• DateTime.diff
• Interval methods
• Duration.reconfigure
• Make iterable

Formatting English months, weekdays, etc shouldn't require formatToParts

We have English strings explicitly, but we don't fall back to them when doing toFormat(), so they fail on pre-formatToParts browsers like IE 11.

Make the Intl polyfill optional

formatToParts landed in the Chrome beta and newish builds of Firefox. That completes the story for them in terms of polyfilless support. Just need to figure out the best way to build this to optionally have it available.

Note that the tests don't pass b/c there are some simple differences in Intl strings, like where commas go, that sort of thing. For now we'll always use the polyfill for tests, even though their Intl strings are objectively worse, because it lets us keep the test code the same across platforms.

offsetNameLong and offsetNameShort break in the absence of Intl support

> DateTime.local().offsetNameShort
'EDT'
> Intl = null
null
> DateTime.local().offsetNameShort
TypeError: Cannot read property 'DateTimeFormat' of null
    at Function.parseZoneInfo (/Users/isaac/code/luxon/build/cjs/luxon.js:2897:15)
    at LocalZone.offsetName (/Users/isaac/code/luxon/build/cjs/luxon.js:2464:19)
    at DateTime.get$$1 (/Users/isaac/code/luxon/build/cjs/luxon.js:7360:26)
    at repl:1:17
    at ContextifyScript.Script.runInThisContext (vm.js:44:33)
    at REPLServer.defaultEval (repl.js:239:29)
    at bound (domain.js:301:14)
    at REPLServer.runBound [as eval] (domain.js:314:12)
    at REPLServer.onLine (repl.js:433:10)
    at emitOne (events.js:120:20)

Fix Intl detection in IE 9 and 10

Using Luxon in IE 9 or 10 currently gives

'Intl' is undefined

It doesn't provide a line number for the error and as far as I can tell, I now hide the use Intl behind a typeof check. So I'm not sure what the problem is.

Test of time diff is not independent of system timezone

'DateTime#diff makes simple diffs' fails for the test that checks for a difference of 80 hours (24 * 3 + 8, lines 55-63 atm). On my machine, the diff functions returns 79 hours instead of the expected 80. This is probably because I'm using the German time zone (CET) and March 27, 2016 is the day where we switched to daylight savings time.

I'm not sure about the correct way to resolve this:

• Use an explicit time zone in the DateTime tests where the test date does not run into DST conflicts and add an additional test for dates where there are DST switches?
• Change dates in the test to a time period where it's unlikely to be DST changes?
• Document how to provide a testing environment set to the correct time zone (i.e. using TZ=America/New_York gulp test instead of gulp test )?

Fail build on doc warnings/incomplete coverage

I can't figure out how to make esdoc actually do this.

toObject() should have an option for including configuration information

Allows symmetry with fromObject()

Add license

Evaluate IE 9 & 10

I have no idea what works and what doesn't on IE 9 and 10. Plan is to:

1. Find out what works
2. Decide what (if anything) should be fixed or polyfilled

I suspect the answer is [shrug], but we'll see.

get rid of parse10()

It is dumb

Add a JS linter

fromObject() should be able to take outputCalendar, locale, and numberingSystem options

toLocaleString() doesn't shift times for fixed-offset zones

Discovered while helping with #59:

var dt = DateTime.local().setZone("UTC-5");
dt.toLocaleString(DateTime.TIME_SIMPLE) //=> '4:04 PM'
dt.hour //=> 11
dt.toUTC().hour //=> 16

In other words, toLocaleString() is showing the UTC time, not the UTC-5 time.

Duration.fromObject() and Interval.fromObject() should have parity with DateTime.fromObject()

Specifically, they should accept configuration info

ISO inputs with just year or year-month should work

Currently:

DateTime.fromISO('2017').isValid //=> false
DateTime.fromISO('2017-05').isValid //=> false

The first should be equivalent to '2017-01-01T00:00:00.000' and the latter should be equal to '2017-05-01T00:00:00.000'

All fromXXX() should take a zone

Current offenders are fromJSDate and fromMilliseconds

Big todo list

After Node 8.0

• Remove Intl polyfill
• Simplify test infra
• Fix existing tests
• Add elided tests
• Rip out fake zones
• Add formatToParts version of dezoner
• Fix formatting for IANA zones
• differentiate L vs M correctly
• Sort out number and calendar settings
• Instant metaformats with zones
• eras
• unhack offset name stuff
• hardcoded English strings (also use them from the RFC parser!)

General stuff

• clean up fromObject interface (zone stuff, mostly)
• clean up fromISO interface (zone stuff, mostly)
• clean up fromString interface (zone stuff, mostly)
• unit aliasing
• settings class
• weeks and weekyears (and matching ISO format)
• day of year (and matching ISO format)
• RFC 2822 parsing
• RFC 2822 formatting
• HTTP date parsing
• HTTP date formatting
• error handling
• Add/subtract for weeks?

Obvious perf issues

• Do some really basic profiling

Invalid

• contagious invalidity
• tests for invalid instances
• optional throw on invalid

Zones

• add local and utc factory methods
• clean up utc/utcOffset/rezone conversion functions (use normalizeZone)
• better zone testing

Intervals

• Formatter
• ISO Parser
• toISO
• toString
• locale and similar parity functions

Durations

• ISO parser
• toString
• Fix ISO formatting for negative duration parts

Documentation

• Install
• Zones/Offsets
• Feature support matrix
• Intl
• Output calendar
• Tokens

Packaging

• Bower
• Webpack
• Require.js
• Browserify
• System.js
• Meteor

Build

• Tests for CI
• Fix CI to use ICU build of Node
• Fail build on doc warnings
• Site w/docs build and distribution files

Demo

• Simple script inclusion
• Require

Add post-commit hook for prettier

You can run gulp format or gulp lint! before committing but it's easy to forget. Would be nice if something just tacked on commits that did that.

question - keeping calendar times from millisecond timestamps

Hi,
I'm a bit confused by this but I'd be happy to make some documentation / examples once I understand it a bit more?
basically we store shift clock ins and clock outs as numerical Date.now() values. This enabled us to diff them very easily for lengths of shifts etc.
However as you can imagine problems arise when we try and display those times across different time zones. We want to keep the calendar time (e.g if they clocked in at 7am, we want it to show 7am everywhere).

I see this example:

var rezoned = local.setZone('America/Los_Angeles', { keepCalendarTime: true });

Although I'm not 100% sure at what stage I'd set the zone in our case. My attempts to set it from the utc time or the millisecond time and then format them using toFormat() seem to just result in them being adjusted for the device's location (i.e the calendar times change)

I've read the docs quite a bit and I still can't figure out how this is possible (except that you recommend storing utc strings, so we will start storing these as well).
We also have access to the timezone of the user's device at each end, although I'm still a bit confused as to where and when we need that.

As I said, an example of how to do this would be amazing and then I could make a pull request showing it in a bit more detail if you'd like?

Backport 2822 fixes from Moment

The Luxon 2822 implementation got ported to Moment, but then some of issues were discovered and then fixed. Some of them might not be relevant, but some of them are. Re-backport them to here. Relevant diff.

Provide common presets for toLocaleString

Should be in line with the macro formats

Fail the tests if `t.end()` is missing

It just silently goes through right now

React Native (Android) can't find variable Intl

Is it possible to use this library in React Native? I'm getting this error on Android. Thanks code causing problem is below:

  const clockInDate = DateTime.fromMillis(shift.clockIn).toLocaleString({
    day: "numeric",
    month: "short",
    weekday: "short"
  });

  const clockOutDate = shift.clockOut
    ? DateTime.fromMillis(shift.clockOut).toLocaleString({
        day: "numeric",
        month: "short",
        weekday: "short"
      })
    : "-";

Edit:
I've found this can be fixed by using this library which seems excellent:
https://github.com/SoftwareMansion/jsc-android-buildscripts

reorder functions in DateTime

Packaging/loading needs

Most of this probably works, but they need tested and documented:

• Bower
• Webpack
• Require.js
• Browserify
• System.js
• Meteor

Add long-term-accurate duration conversions

toLocaleString should default to the user's locale, not just en-US

en-US is a good default for parsing and a good fallback for when features are missing, but it doesn't make much sense for human readable strings. In the absence of overrides, I suspect the default should just be the user's locale, consistent with how the native one works on its own (I think).

set() should be able to set the zone

Should be identical to fromObject() in form

Make dots other punctuation optional in fromString

DateTime.fromString is very picky about parsing. A month name has to exactly match what Luxon expects:

DateTime.fromString('févr.', 'MMM', { locale: 'fr'}).isValid //=> true
DateTime.fromString('Févr.', 'MMM', { locale: 'fr'}).isValid //=> true
DateTime.fromString('fevr.', 'MMM', { locale: 'fr'}).isValid //=> false
DateTime.fromString('févr', 'MMM', { locale: 'fr'}).isValid //=> false

I'm not sure how to desensitize the accents (or if that is even desirable), but I think the dots ought to be optional. Should be easy enough to inject ? into the regexes before trying them.

Why are the tests so slow on Travis?

It is a mystery.

Degrade gracefully in the absence of platform features

• Using IANA zone without Intl support (IE 10?)
• Using IANA zone without zone support (FF < 56 or IE 11)
• Using toLocaleString() without Intl support (IE 10?)
• Using parse/format without Intl support (IE 11)
• Using parse/format/listers without formatToParts (FF < 56 or IE 11)

toLocaleParts errors in the absence of Intl

> Intl = null
null
> DateTime.local().toLocaleParts()
TypeError: df.formatToParts is not a function
    at Formatter.formatDateTimeParts (/Users/isaac/code/luxon/build/cjs/luxon.js:3582:17)
    at DateTime.toLocaleParts (/Users/isaac/code/luxon/build/cjs/luxon.js:6785:74)
    at repl:1:18
    at ContextifyScript.Script.runInThisContext (vm.js:44:33)
    at REPLServer.defaultEval (repl.js:239:29)
    at bound (domain.js:301:14)
    at REPLServer.runBound [as eval] (domain.js:314:12)
    at REPLServer.onLine (repl.js:433:10)
    at emitOne (events.js:120:20)
    at REPLServer.emit (events.js:210:7)

The fix is to add formatToParts to our little miniature DateTimeFormat polyfill.