moment / moment

Parse, validate, manipulate, and display dates in javascript.

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.

moment's Issues

All "format timezone" tests fail for me in Chrome and FF, but pass in IE9

via http://www.momentjs.com/test/

Chrome:
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.106 Safari/535.2
Tests completed in 72 milliseconds.
621 tests of 633 passed, 12 failed.

FF:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Tests completed in 70 milliseconds.
621 tests of 633 passed, 12 failed.

IE9:

Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MDDC; InfoPath.2; .NET4.0C; .NET4.0E)
Tests completed in 189 milliseconds.
633 tests of 633 passed, 0 failed.

(lulz at IE9's duration)

Add moment.fn.closest()

See requirements here

https://gist.github.com/1280098

Add time specific diffs

Placeholder issue for adding the functionality.

Committed in b82b34b

error on documentation regarding constructor

The parser ignores non-alphanumeric characters, so both moment("12-25-1995", "MM-DD-YYYY")and moment("12��995", "MM-DD-YYYY")will return the same thing.

may be it should say:

The parser ignores non-alphanumeric characters, so both moment("12-25-1995", "MM-DD-YYYY")and moment("12-25-1��995", "MMDDYYYY")will return the same thing.

use conventional syntax for formatting

I don't know why you invented your own format specifiers, but things like stftime (and that family of methods) have a well known set of format specifiers. Would be nice if you could just use those instead of making new ones which won't match up to what someone may already be using.

A localized format with abbreviated month would be nice

It would really be nice to have a localized format that uses abbreviated month names (like Java's DateFormat.MEDIUM).

Allow numbers and letters as field separators in parsing format

For instance, when parsing a ISO-8601 date string where the letter T is a separator between the date and the time values. The following code sample results incorrectly as 2011-11-01T00:11:11.

moment("2011-11-11T11:11:11", "YYYY-MM-DDTHH:mm:ss").format("YYYY-MM-DDTHH:mm:ss");

This is due to the regex [0-9a-zA-Z] in the format to array parsing ending up with a token DDTHH instead of DD and HH being separate tokens. My suggestion would be introducing an escape character for alphanumeric separators.

AM/PM should be part of i18n

I think AM/PM should be part of i18n.

For example,
10:30 AM => 오전 10:30 (Korean)

iso8601

Hey,

Do you plan on supporting iso8601? It would be really nice as the javascript Date object doesn't support it.

Thanks

Issues with Safari

I know this is mainly a node based library, but I happen to use this library on the browser side. I noticed some issues when parsing dates in Safari.

I resorted to creating a function in my app that does this before it sends the date to _.date (sorry this is coffeescript)

parseDate: (str) ->
  parts = _.map str.split("-"), (part) -> parseInt(part)
  date = new Date(parts[0], parts[1]-1, parts[2])

The date strings are YYYY-MM-DD. Works in every other browser, so I'm not sure if you want to implement manual parsing or not but if you want to support Safari you're going to have to. :-/

Custom, LDML-like pattern language which is not LDML

Why does moment create yet another custom datetime pattern language instead of using LDML's date formats patterns?

namespace

Hi!

Wouldn't it be cleaner to mixin all these methods as a separate object, say, _.time? Just like they did in JS when they separated Date, Math and so on?

Best regards,
--Vladimir

Graceful failure tests

Add tests for graceful failures.

moment('10', 'MM-DD-YYYY')
moment.lang('undef') - NodeJS + browser.

Add _date.native() to retrieve the native Date object

Right now, there is no official way to retrieve the native Date object. You could access it before by _date().date, but that will break when adding the getters and setters, as the internal date object will be called _date._d.

There should be a function that returns the native date object that is safe in the future.

Add documentation for moment.fn.isDST

See issue #81 and #78

Add convenience methods

Add convenience methods for accessing the getters and setters of the date parts

_date().month() == new Date().getMonth()

_date().month(5) = new Date().setMonth(5)

Chaining should also be allowed.

_date.month(5).date(3)

Add _date.fn to allow for prototype modification

_date.fn == UnderscoreDate.prototype

Add some common masks

pulled from another library...

"default":      "ddd mmm dd yyyy HH:MM:ss",
shortDate:      "m/d/yy",
mediumDate:     "mmm d, yyyy",
longDate:       "mmmm d, yyyy",
fullDate:       "dddd, mmmm d, yyyy",
shortTime:      "h:MM TT",
mediumTime:     "h:MM:ss TT",
longTime:       "h:MM:ss TT Z",
isoDate:        "yyyy-mm-dd",
isoTime:        "HH:MM:ss",
isoDateTime:    "yyyy-mm-dd'T'HH:MM:ss",
isoUtcDateTime: "UTC:yyyy-mm-dd'T'HH:MM:ss'Z'",
fbDateTime:     "mmm dS @ h:MMtt"

"1 minutes ago" instead of "a minute ago"

Hi,

I notice from your readme there's a special case to show "a minute ago" but the simplest _date(myTicks).fromNow() test-case still gives me "1 minutes ago". What to do?

Add sugar for add / substract like datejs

For example

instead of
_date.add( { d:3 } )

we could write

_date.addDays(3)

Same again for hours/weeks etc

Also should be chainable, so
_date.addWeeks(1).subtractDays(2)

This really increases readability in complex date manipulation.

Add _date().diff()

Just returns the diff of two dates numerically.

Should replace _date().from(date, true, true)

Adding across DST results in a difference of an hour

// create a date outside of Daylight Savings Time
var m = moment(new Date(2011, 0, 1, 0, 0, 0));
m.format('h:mm a');
// 12:00 am

// change it to a date inside Daylight Savings Time
m.add('weeks', 20);
m.format('h:mm a');
// 1:00 am

If we cross the DST line by adding days, this also occurs

// the day before DST in the US
var m = moment(new Date(2011, 2, 12, 5, 0, 0));
m.format('h:mm a');
// 5:00 am

// DST day in the US
m.add('days', 1);
m.format('h:mm a');
// 6:00 am

Bundle and minify language files

Add a step to the build script to jshint and minify the lang files for delivery to the browser.

Add a step to bundle the lang and lang test files for testing.

Add unit tests and documentation for moment.fn.zone

See this commit:

3aa1ad5

FF and Chrome inconsistency - Firefox is one day shorter

Try this code in FF 5.0.1 and Chrome (Mac):

var today = _date().format('YYYY-MM-DD');
var today_plus_7 = _date(today).add({ d: 7 }).format('YYYY-MM-DD');
console.log(today, today_plus_7);

http://jsfiddle.net/jboesch26/b3wkM/

Chrome will log 7 days from the "today" date, Firefox will log 6 days. :(

Also, the unit tests fail in Firefox 5.0.1 and Chrome on a Mac.

Timezone Translation

I currently store my dates in UTC, and I'd like to use Moment.js and jQuery to translate them into the local timezone. Is Moment.js capable of doing this?

moment doesn't compile with closure compiler

Thanks for a nice library.

Using: http://code.google.com/closure/compiler/

Around line 403 is this:

    native : function () {
        return this._d;
    },

http://en.wikibooks.org/wiki/JavaScript/Reserved_Words

native is a reserved word in ECMAScript v3.

Commenting out the above code makes things compile.

Minified version breaks Underscore.js mixin

_.date is undefined with the current minified version. I ran the un-minified version through YUI's compressor and it worked fine. Size difference was minimal (original compressed: 4292, YUI compressed: 4433).

invalid parse if not using separator

I'm getting this:

moment('15112011', 'DDMMYYYY').year() == 43275

using any separator, it works

moment('15/11/2011', 'DD/MM/YYYY').year() == 2011

Timezone localization in unit tests is tied to PST

lang-tests.js expects to see 'zz' localize to 'PST', which fails in other timezones.

I’ve been trying to figure a way round this without introducing extra untested logic or crazy mock-dates, but so far have drawn a blank, so posting it up for discussion…

Moments can't be cloned

This was unexpected for me:

var first = moment('2011-11-11');
var second = moment(first);
first.add('days', 1);
second.valueOf() === first.valueOf(); // true!

The second line assigns the same Date object to the new moment, so whenever the first changes, the second does too.

This is a workaround:

var second = moment(first.valueOf());

But it's not really intuitive. I think it'd be nice for the constructor to handle that for you - and/or add a clone() method.

Add documentation for parsing and formatting timezones

Add moment.zone() to support multiple time zones.

moment.zone() should return the default timezone.
moment.zone(number) should change the default timezone.

Each moment should have a timezone.

moment.fn.zone() should return that moment's timezone.
moment.fn.zone(number) should change that moment's timezone.

Upon creation, each moment should set it's timezone to the default timezone.

Versioning

Hi Tim,

this looks very awesome, about to play with it now. Minor nitpick: I chose release 0.5.1 from the Downloads button here but package.json and underscore.date.js state 0.5.0... did I miss out on the 0.5.1 additions or did the number just not get bumped up in these source files?

Use of `float` as a variable name

Google's Closure Compiler is unable to deal with moment.js as it considers float a future reserved word which it has probably taken from the es3 spec (interestingly enough, not es5).

I don't necessarily think this should be "fixed", but thought it potentially useful to document the issue here in case anyone else stumbles across the same problem.

Add timezone information to parser and formatter

Moment.js does not support parsing dates formatted according to ISO8601 (with timezone offset). Most browsers support that format natively, but IE9 doesn't.

Feature: improved parsing

I've searched the net on many occasions trying to find a good date library. In primarily use two features: parsing and formatting. Of the two, most date libraries are sufficient in the formatting category. It's parsing that usually lacks. The native Date.parse is weak as it cannot parse a lot of common date formats. Also, it is not that useful to be required to pass a second parameter to a parse function in order to specify the date template from which to parse. In most cases, I grab my dates from some input field (perhaps a text field). I generally allow the person to enter the date in whatever format he sees fit. As such, I just wanna pass a date (no format template) over to a parse function and have it decipher the date if possible and return it as a date object.

Sugar.js does this but it modifies all native object prototypes (which I'm not necessarily against). The trouble is it comes with a lot of other baggage. It's date library is not yet separate.

I've even tried date.js and find that it doesn't always successfully parse a date in some format.

Anyway, I know this is a biggie. So I'll take no offense if you opt to close it. :)

Wrap with _date() instead of _date.date()

Hey,

Have you thought of setting _date up so that it could be used like Underscore with _date(foo).format(...)?
What was your reason to require typing 'date' twice (as in _date.date(foo).format(...))? :)

Andri

Add tests for all languages

All new languages should have tests for _date.fn.format and _date.fn.from.

Passing null as dateTimeString to moment(dateTimeString, format) should give null out, not error

Se title

Offset changes when using add() with different options on NOW

I don’t suppose this is intentional?

_.date().add({d : 14})     // -> date: Fri Oct 14 2011 11:42:25 GMT+0300 (EEST)
_.date().add({M : 2})      // -> date: Wed Nov 30 2011 11:42:38 GMT+0200 (EET)

parse by month name not supported?

var str = moment([2011, 11, 19]).format('DD-MMM-YYYY');
console.log(moment(str, 'DD-MMM-YYYY').native().toString());
// ==> "Tue Dec 19 1899 00:00:00 GMT+0800 (China Standard Time)"

i18n: format date

First I just want to say that this is a great lib, gets the job done and has great i18n support.

Anyway, I'm dealing with a website that has to show dates both in english and in portuguese (great to see that pt was already implemented!). It was all good, until I found this place where I need to write a full date in both languages.

I realized I would need 2 different formats: one for english (MMMM D, YYYY - October 20, 2011) and one for portuguese (D \de MMMM \de YYYY - 20 de Outubro de 2011 [and just now I see that I don't know if it's possible to escape the lowercase d, but anyway, focus]).

Is there a way to call moment().format() with no parameters so that it assumes a default formatting for the whole date?

If there isn't, it would be nice to implement it, I could give it a go.

Maybe a new token that contains the whole date and whole time, like moment().format('T'); // 2:17 PM in english and 14:17 in portuguese. Though I have no idea what a good token would be for the whole date...

Meridiem is misspelled as meridian

https://github.com/timrwood/moment/blob/52216a525ba4f6a2bd1eb85a9d99b17823da3a59/moment.js#L366

Why use split() to create array?

I like looking at other peoples' code because I always seem to learn something new. As I was looking through moment.js I noticed you initialize some member variables with split() to create an array instead of just creating an array. So, what's the reasoning for doing this:

shortcuts = 'Month|Date|Hours|Minutes|Seconds'.split('|')

instead of this:

shortcuts = ["Month","Date","Hours","Minutes","Seconds"]

Thanks!

fromNow() on dates in the past is wrong

Today is 2011-11-14.

var aWhileAgo = moment([2011, 10, 30]);
console.log(aWhileAgo.fromNow());
"in 15 days"

var aWhileAgo = moment([2011, 11, 5]);
console.log(aWhileAgo.fromNow());
"in 20 days"

var aWhileAgo = moment([2010, 11, 5]);
console.log(aWhileAgo.fromNow());
"11 months ago"

var aWhileAgo = moment([2011, 10, 5]);
console.log(aWhileAgo.fromNow());
"10 days ago"

It seems that fromNow() is broken for dates in the recent past.

Add a package.json

Hi,

I would like to use underscore.date in nodejs. Can you add a package.json and publish it with npm ?

Thanks

Add speed comparisons for DateJS, phpjs.date, Jacob Wright, Steven Levithan, jPaq

http://jpaq.org/documentation/Date.prototype.format%28%29/1.0/
http://blog.stevenlevithan.com/archives/date-time-format
http://jacwright.com/projects/javascript/date_format/

Validation

I would like to use moment in a project, but it does not provide any kind of reliable validation. For example:

> moment("yams", "HH:ss")
{ _d: Mon, 01 Jan 1900 05:00:00 GMT }

Unfortunately moment treats "yams" as a valid date string because it has "am" in it. Ideally, when the input doesn't match the provided format string, it would somehow present an error instead of continuing as if the user had actually given valid input.

French locale

I came to the website today and found the site displaying this in French.

Jeudi, Novembre 10er 2011, 4:55:30 pm

just wanted to point out that 10er is not correct it should be only 10. the suffix -er is only used for 1. Otherwise no suffixes are used in dates.