I'm working on a project and momentjs is really useful for date manipulation so thanks for that.

To give you an example, we're making somekind of store for plane tickets. The duration.humanize() function is way to imprecise for us.

For example when leaving at: 12:00 and landing at 13:30. It will round it to 2 hours. But we need some kind of granularity which is missing from momentjs.

humanize could default to 1 level of precision starting from the highest value.

// 1:30
duration.humanize()
2 hour
duration.humanize({precision: 2})
1 hour 30 minutes
duration.humanize({precision: 3})
1 hour 30 minutes 0 seconds

The second problem is when there is the number 0. Momentjs translates it as "few seconds". I'm not so sure how it could be achieved but it would be cool to have some kind of formatting.

// 3 days and 0 minutes
duration.format('D [and] M')
> 3 days and 0 minutes
duration.format('H [and] M')
> 72 hours and 0 minutes
duration.format('H [and] m')
> 72 hours and few minutes

That way the highest value could be mapped in the format. So even if there is 1 year, the format tells us how to display it correctly. I'd be happy to push a commit for that because it's very useful and having to do it by hand when momentjs already handle localization feels bad.

There has been a lot of discussions about this. Here's the proposal:

The following mutable methods will become immutable in 3.0.0: utc, local, zone, add, subtract, startOf, endOf, lang, also in duration: add, subtract, and lang.

As a start, all methods will be duplicated with methodNameMute variants. We also need immutable variants named methodNameImmute. From 3.0 the plain old methods will start using the immutable option by default.

What is debatable is:

• should lang be made immutable
• should all the getters/setters (including get/set) be made immutable too
• naming of the mutable and immutable versions of the methods
• and of course -- should we do the switch, or just stop at the immutable API

The good part is we can make immutable versions of the methods today and decide later on what to do. If we switch it would also mean the 2.x branch would be around for quite some time after 3.x is out.

@icambron @timrwood @gregwebs @yang @lfnavess @soswow @langalex

Edit: If you set your dependency to 2.18.1, everything will be fine. We are coordinating with some other libraries to find a permanent solution Edit 2 : Set "moment": "2.18.1" in your package.json Edit 3: We believe this is fixed.

Hello. Using create-react-app. After updating moment to 2.19.0 i have this error on load :

Error: Cannot find module "./locale" -> 9 stack frames were collapsed. ./src/utils/Utils.js src/utils/Utils.js:1

1 | import moment from 'moment'

If you clicked on the warning link and landed here:

moment construction using a non-iso string is deprecated. What this means is you can safely do

> moment("2014-04-25T01:32:21.196Z");  // iso string, utc timezone
> moment("2014-04-25T01:32:21.196+0600");  // iso string with timezone
> moment("2014 04 25", "YYYY MM DD"); // string with format

but you can't do reliably (therefore its being deprecated)

> moment("2014/04/25");
> moment("Thu Apr 24 2014 12:32:21 GMT-0700 (PDT)");
> moment("some random string that looks like date");

In the upcoming releases a few more well defined formats might be added, but the general idea of using any random string to construct a date is no more. If you really want that behavior just do moment(new Date("random string that contains date")), but moment won't be responsible for such convertions. Read below for the rationale about the change

As described in https://github.com/moment/moment/issues/1403#issuecomment-31961590, but also recent debugging c4d9f6e and 94d6c90 caused by https://travis-ci.org/moment/moment/builds/16672288 brings me to the conclusion that

using Date to create a moment from string, passed from the user is extremely unpredictable, and it turns out to work somewhat and then bite you in an edge case when you're not careful

So I think we need an option to disable it, for tests at the very least. I've debugged that numerous times thank to our old friend IE6 and friends.

You'd pass a string only, hoping that it would hit one of the predefined formats, but instead it hits Date and it sort-of works, sometimes. I think it should be clear to users when they're hitting this case, and that it might not work well on all browsers.

The only use-case for using Date to parse input is when a) it is entered by a web user (moment's user's user :)) and b) the web user can see how we're interpreting the date entered. Every other case is just silently waiting to break at some point.

I remember when moment was a "lightweight" library, right now at 12kb (gziped no less) for, what it's in most cases, just very very simple date manipulation.

A simple solution to this problem would be to modularize momentjs so at least for environments like browerify, webpack and such a minimal version can be obtained.

eg.

Regular usage can stay the same,

// get everything under the sun
var moment = require('moment');

Modular usage could look like this,

// get core, the core does nothing, no validation, no nothing
// it would only define a internal storage structure and the bare minimum
// methods for getting values out of it: day, month, year, etc (no "format" 
// functions or "fromNow" since you might not even want to use them)
var moment = require('moment/core');

// add plugins for all the stuff you need, if you ever want ALL of them you 
// just include the directory instead (node/browserify/webpack will pick up
// a index.js inside it that would have all the things)
moment.plugin([

    // if you know this is all the parsers you need this is all you add
    require('moment/plugins/parser/yyyy-mm-dd-time'),
    require('moment/plugins/parser/unixtime'),

    require('moment/plugins/validator/yyyy-mm-dd-time'),
    // if we don't use unixtime locally, only on server we dont care for that
    // when it comes to validation

    require('moment/plugins/fromNow'),
    require('moment/plugins/toUnixTime'),

    // with a modular structure we can add 3rd party stuff really easily
    require('moment-phpstyle-format'),
    require('moment-chained-functions-format')

]);

// lock in the configuration so that calling plugin method throw and exception
// this would be irreversible but you can get a unlocked version by calling copy
// this will force people to get a "copy" of the configuration before doing 
// anything stupid -- or help them find the mistake if they add it later
moment.lock();

// you now just include this file where you need it
module.exports = moment;

Let's pretend the above is in something like lib/moment and represents your default boilerplate configuration for it. Obviously you may eventually encounter situations where you need more advanced functions. If we add to the default boilerplate we unfortunately add to every other context that doesn't need it. This is a big bummer if we're trying to keep client size down with things like webpack code splitting.

However, so long as the modular system is capable of being extending any time there's no problem whatsoeve. Ideally, to avoid subtle race condition bugs, we should be able to get a new "advanced" version as a separate instance:

// load boilerplate we defined previously
// we request a copy of the instance so no funny business happens
var moment = require('lib/moment').copy(); 

// we can also create a separate boilerplate if we re-use this a lot
moment.plugin(require('expensive-internationalization-timezone-nonsense'));
moment.lock(); // lock the new copy just in case its passed around

// moment instances should be able to do a quick copy between instances
// to ensure functionality, ie. moment(createdAt) could just swap plugin pointers

Now only the module that actually uses that feature pays the cost. If you use moment in 100 places and only 1 actually needs internationalization just that one place will ever pay for it. This applies to all functions, all the core needs to do is store a plain date object and some getters. Is everything you do just pass unix time from the server? you can just have unixtime parser. Do you only ever validate dates on the server? you can skip on any and all validation, etc.

It's effectively as light as you building your own specialized helpers. And much like projects like gulp, postcss and so on the community can contribute easily to it though easily maintainable chunks.

And in this way, momentjs can, once again, be called "lightweight javascript date library".

We've touched on this before in #463 and #879 but never really talked about it directly in its own issue.

We need a method for formatting durations similar to how we format dates. It should be as simple as:

moment.duration(x).format("H:mm:ss")

Note that the formatting tokens would have to carry slightly different meaning, since we're representing an elapsed duration of time, rather than a time-of-day. I suggest the following:

• hh would mean "hours remainder after accounting for days"
• h would be the single digit form of hh
• HH would mean "total whole hours"
• H would be the single digit form of HH
• HHH would mean "total hours including decimals" - although that can currently be done with duration.asHours(), so this might not be necessary.

Similar formatting would apply for other units. In this context, the highest unit would be a "day", which would be a standard day consisting of 24 standard hours. It wouldn't make sense to measure years or months with this due to calendaring issues.

Note, this came up recently (again) on StackOverflow in this question. The user was looking for something like duration.format("H:mm:ss"). This is the workaround:

Math.floor(duration.asHours()) + moment.utc(duration.asMilliseconds()).format(":mm:ss")

This works, but it feels hacky. This should be built in.

.humanize isn't really accurate when it comes to seconds.

moment.duration(40, 's').humanize() === "a few seconds" // expected "40 seconds"
moment.duration(45, 's').humanize() === "a minute" // expected "45 seconds"

I understand that we don't often want this level of accuracy but sometimes we do want the exact value in a human readable way.

I suggest a change to the API (which seems backwards compatible from what I actually see) to support this feature:

moment.duration(40, 's').humanize() === "a few seconds"
moment.duration(40, 's').humanize(true) === "in a few seconds"

moment.duration(40, 's').humanize({precise:true}) === "40 seconds"

moment.duration(40, 's').humanize({suffix:true, precise:true}) === "in 40 seconds"
moment.duration(40, 's').humanize({precise:false, suffix:true}) === "in a few seconds"

What do you think ?

Hi,

I've tried the following imports in node, to execute moment.format( date ) but all of them fail with: format is undefined.

import moment from 'moment'
import { moment } from 'moment'
import * as moment from 'moment'

How is the correct way of importing this library from es6?

Thanks in advance!

Round up, down or to the nearest unit.

Usage: moment.roundTo(units, [offset, midpoint])

m.roundTo('minute', 15); // Round the moment to the nearest 15 minutes. m.roundTo('minute', 15, 'up'); // Round the moment up to the nearest 15 minutes. m.roundTo('minute', 15, 'down'); // Round the moment down to the nearest 15 minutes.

Describe the bug I get this error on chrome console after I build the production optimized build

Uncaught Error: Cannot find module './locale' at 2.d0944550.chunk.js:1 at Module. (2.d0944550.chunk.js:1) at f ((index):1) at Module.837 (main.091f08fc.chunk.js:1) at f ((index):1) at Object.540 (main.091f08fc.chunk.js:1) at f ((index):1) at a ((index):1) at Array.e [as push] ((index):1) at main.091f08fc.chunk.js:1

This is my package.json

{
  "name": "sheetgo-front-end",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "@allpro/react-router-pause": "^1.1.3",
    "@material-ui/core": "^4.4.2",
    "@material-ui/icons": "^4.5.1",
    "@material-ui/lab": "^4.0.0-alpha.26",
    "@material-ui/styles": "^4.4.1",
    "@material/icon-button": "^3.1.0",
    "@material/react-button": "^0.15.0",
    "@material/react-card": "^0.15.0",
    "@material/react-icon-button": "^0.15.0",
    "@material/react-material-icon": "^0.15.0",
    "@material/react-select": "^0.15.0",
    "@material/react-tab": "^0.15.0",
    "@mdi/js": "^3.4.93",
    "@mdi/react": "^1.1.0",
    "@stripe/react-stripe-js": "^1.1.0",
    "@stripe/stripe-js": "^1.2.0",
    "@svgr/webpack": "^4.1.0",
    "apexcharts": "^3.8.6",
    "axios": "^0.19.2",
    "browser-info": "^1.2.0",
    "chart.js": "^2.7.2",
    "classnames": "^2.2.6",
    "color-sort": "^0.0.1",
    "connected-react-router": "^6.5.2",
    "countup.js": "^1.9.3",
    "cra-append-sw": "^2.7.0",
    "filepond": "4.1.0",
    "filepond-plugin-file-validate-size": "2.1.1",
    "filepond-plugin-file-validate-type": "1.2.2",
    "form-serialize": "^0.7.2",
    "fuse.js": "^3.4.2",
    "history": "^4.10.1",
    "inputmask": "^4.0.0",
    "is-mobile": "^2.0.0",
    "jquery": "^3.3.1",
    "jquery-ui-sortable-npm": "^1.0.0",
    "js-cookie": "^2.2.0",
    "lodash": "^4.17.10",
    "markdown-to-jsx": "^6.10.3",
    "material-components-web": "^3.1.0",
    "material-ui-chip-input": "^1.0.0",
    "md5": "^2.2.1",
    "memoize-one": "^5.0.4",
    "moment": "^2.22.2",
    "moment-timezone": "^0.5.27",
    "onecolor": "^3.1.0",
    "p-queue": "^6.1.1",
    "payform": "^1.2.2",
    "promise-throttle": "^1.0.0",
    "prop-types": "^15.7.0",
    "query-string": "^6.5.0",
    "react": "^16.8.1",
    "react-apexcharts": "^1.3.3",
    "react-dom": "^16.8.1",
    "react-draggable": "4.2.0",
    "react-filepond": "7.0.1",
    "react-google-authorize": "^1.0.4",
    "react-hotjar": "^2.0.0",
    "react-id-swiper": "^1.6.8",
    "react-intl": "^2.5.0",
    "react-modal-video": "^1.2.3",
    "react-redux": "^7.1.1",
    "react-resizable": "^1.8.0",
    "react-router": "^5.1.2",
    "react-router-dom": "^5.1.2",
    "react-router-last-location": "^2.0.1",
    "react-scripts": "^2.1.4",
    "react-sizeme": "^2.5.2",
    "react-stripe-elements": "^4.0.0",
    "react-text-mask": "^5.4.3",
    "react-virtualized-auto-sizer": "^1.0.2",
    "react-vis-network": "^1.0.0",
    "react-window": "^1.8.1",
    "recompose": "^0.30.0",
    "redux": "^4.0.4",
    "redux-react-session": "^2.4.0",
    "redux-saga": "^1.1.1",
    "redux-thunk": "^2.3.0",
    "socket.io-client": "^2.3.0",
    "sort-by": "^1.2.0",
    "tether": "^1.4.4",
    "throttle-debounce": "^2.1.0",
    "url-loader": "^1.0.1"
  }

If I build locally with yarn for the dev version it works

To Reproduce Steps to reproduce the behavior: Build an app with those requirements. Should get that error on console.

Expected behavior A clear and concise description of what you expected to happen.

Screenshots If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Moment-specific environment

• The time zone setting of the machine the code is running on
• The time and date at which the code was run
• Other libraries in use (TypeScript, Immutable.js, etc)

Please run the following code in your environment and include the output:

console.log((new Date()).toString())
console.log((new Date()).toLocaleString())
console.log((new Date()).getTimezoneOffset())
console.log(navigator.userAgent)
console.log(moment.version)

Additional context Add any other context about the problem here.

WARNING in ./node_modules/moment/src/lib/locale/locales.js
Module not found: Error: Can't resolve './locale' in 'D:\project-fed\ecloud\client-web\node_modules\moment\src\lib\locale'

I found that there is something wrong with the function below

function loadLocale(name) {
    var oldLocale = null;
    // TODO: Find a better way to register and load all the locales in Node
    if (!locales[name] && (typeof module !== 'undefined') &&
            module && module.exports) {
        try {
            oldLocale = globalLocale._abbr;
            var aliasedRequire = require;
            aliasedRequire('./locale/' + name);
            getSetGlobalLocale(oldLocale);
        } catch (e) {}
    }
    return locales[name];
}

aliasedRequire('./locale/' + name);, should it be ../locale/ ?

Describe the bug ① moment.updateLocale("zh-cn", { week: { dow: 6, doy: 12 } }) ② moment("2022-12-31").format("YYYY-ww") // '2022-01' ----error moment("2023-01-01").format("YYYY-ww") // '2023-01' moment("2022-12-30").format("YYYY-WW") // '2022-52'

To Reproduce Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior moment("2022-12-31").format("YYYY-ww") // '2022-52'

Screenshots If applicable, add screenshots to help explain your problem.

How can I change the font color or size of (AM/PM) without separating it from the hour? I am using this code to translate it.

moment.updateLocale("en", { meridiem: function (hour, minute, isLowercase) { if (hour >= 12) return isLowercase ? "pm" : "PM"; else return isLowercase ? "am" : "AM"; }, });

Is there a chance to make the font a little smaller to have a friendly UI?

Describe the bug day(..) behaves differently depending on the day of the week. day(1) on a sunday will move the date to monday of the next week. day(1) on any other day will move the date to monday within the current week.

To Reproduce Either go to https://jsfiddle.net/wvnx2q6a/ or use the code below:

console.log("Testing January 1st 2023 on a sunday");
var m = moment("2023-01-01T00:00:00.000+00:00"); // January 1st 2023 (sunday)
console.log("Date " + m.format("YYYY-MM-DD") + " in week " + m.isoWeek());
m.day(1); // We need monday within this week - BUT it moves date to next week (bug?)
console.log("Date " + m.format("YYYY-MM-DD") + " in week " + m.isoWeek());

console.log("Testing January 3rd 2023 on a tuesday");
m = moment("2023-01-03T00:00:00.000+00:00"); // January 3rd 2023 (tuesday)
console.log("Date " + m.format("YYYY-MM-DD") + " in week " + m.isoWeek());
m.day(1); // We need monday within this week - it remains within week as expected
console.log("Date " + m.format("YYYY-MM-DD") + " in week " + m.isoWeek());

Notice how the first example changes the week number while the second example keeps the current week number.

Expected behavior I would expect day(..) to never change the week number when the argument value is between 0-6

Desktop (please complete the following information):

• OS: macOS Monterey 12.6 (21G115)
• Browser: Chrome 108.0.5359.124 (Official Build) (x86_64)
• Version: Moment 2.29.4

Please run the following code in your environment and include the output:

console.log((new Date()).toString())
console.log((new Date()).toLocaleString())
console.log((new Date()).getTimezoneOffset())
console.log(navigator.userAgent)
console.log(moment.version)

Result: Tue Jan 03 2023 13:16:36 GMT+0100 (Central European Standard Time) 13:16:36.763 03/01/2023, 13:16:36 13:16:36.763 -60 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36

js code:

date = '2022-12-31'

$result = dayjs(date).add(6, 'month').subtract(1, 'day').format('YYYY-MM-DD')

$result is 2023-6-29

PHP code:

$start = '2022-12-31';

$end = strtotime("{$start} +6 month -1 day");

$result = date('Y-m-d', $end);

$result is 2023-6-30

It's New Year's Eve, and I just saw this bug when the clocks went after midnight and the year turned to 2023.

// moment() is currently Sun Jan 01 2023 00:42:00 GMT+0000
const startOfWeek = moment().startOf('week')

console.log(startOfWeek) // Mon Dec 25 2023 00:00:00 GMT+0000

The year should have been 2022

Happy New Year!!!

have this following node js code:

let pureDate = new Date('2022-12-22T00:00:00.000Z')
console.log(pureDate)
let formatted1 = moment(pureDate).format('YYYY-MM-DDTHH:00:00+hh:mm')
console.log(formatted1)
let formatted2 = moment.utc(pureDate).local().format('YYYY-MM-DDTHH:00:00+hh:mm')
console.log(formatted2)

When I run it at my Windows 10 local machine (+07:00), it print to console:

2022-12-22T00:00:00.000Z
2022-12-22T07:00:00+07:00
2022-12-22T07:00:00+07:00

Now I change timezone to +12:00 and rerun the code, it print:

2022-12-22T00:00:00.000Z
2022-12-22T12:00:00+12:00
2022-12-22T12:00:00+12:00

Everything were fine

Now I deploy it to aws lambda using cloudformation:

Resources:
  timerHandler:
    Type: AWS::Serverless::Function
    Properties:
      Handler: src.timerHandler
      Runtime: nodejs16.x
      Environment:
        Variables:
          NODE_ENV: lc
      Timeout: 100
      Events:
        ScheduledEvent:
          Type: Schedule
          Properties:
            Schedule: "rate(15 minutes)"

After sometime, I access the log and see (please scroll to right-end):

2022-12-22T22:47:04.451+07:00   2022-12-22T15:47:04.451Z e55ee401-87fd-4614-a7c6-971973ccccc6 INFO pureDate: 2022-12-22T00:00:00.000Z

2022-12-22T22:47:04.451+07:00   2022-12-22T15:47:04.451Z e55ee401-87fd-4614-a7c6-971973ccccc6 INFO formatted1: 2022-12-22T00:00:00+12:00

2022-12-22T22:47:04.451+07:00   2022-12-22T15:47:04.451Z e55ee401-87fd-4614-a7c6-971973ccccc6 INFO formatted2: 2022-12-22T00:00:00+12:00

The time 00:00:00 is correct, but the zone +12:00 is not. I would expect the formatted should be 2022-12-22T12:00:00+12:00 or 2022-12-22T00:00:00+00:00

Is that the problem of momentjs, or my code, or lambda? How can I fix it?

moment version: "^2.29.4"

=============================================================================

UPDATE:

This is zone information of the lambda execution:

2022-12-22T23:46:32.052+07:00   2022-12-22T16:46:32.052Z f1d04019-44e7-463a-af1d-faf2a5043887 INFO zone_name: Africa/Abidjan

2022-12-22T23:46:32.052+07:00   2022-12-22T16:46:32.052Z f1d04019-44e7-463a-af1d-faf2a5043887 INFO timezone: GMT

=============================================================================

UPDATE:

Also tried to set TZ variable to UTC but the same issue