moment('')Īrithmetic is another area where the native Date object is lacking. This is not something that will change with the adoption of ES2015. With Moment, the date is always interpreted as local time, unless you specify otherwise. This is in it's own way bad as it has numerous negative back compatibility implications. The ES2015 spec fixes this mistake, bringing it in line with the ISO8601 specification, which specifies local time absent of offset.
MOMENT JS MINUS MINUTES ISO
The value of an absent time zone offset is "Z"Įffectively what this means is that ISO 8601 dates without an offset are to be treated as UTC values, creating the following oddity: //US local format In addition, the ECMA Script 5 Specification makes an unusual assertion about the offset of ISO 8601 dates: Moment's parser handles it just fine though: moment('', 'DD/MM/YYYY', true).format() There is no good work-around for this behavior with the native Date object. var a = new Date('') //Decemin DD/MM/YYYY format For instance, suppose I am using a computer in the United States, but I have a date in DD/MM/YYYY format. Parsing is notably unpredictable with native date. In doing this, Moment.js extends the functionality and also accounts for several deficiencies in the object. Moment.js provides a wrapper for the native JavaScript date object. It does not provide support for adjusting dates based on time zone data - this is provided by the Moment TimeZone library.įor an in depth description of this issue, see the Stack Overflow tag. The Moment.js core library provides functionality related to adjusting times based on an offset value. Several time zones may have the same offset at some point during the year.įor example, the time zones America/Chicago, America/Denver, and America/Belize all have an offset of -06:00 at varying times.įor this reason, it is impossible to infer a time zone from just an offset value. It is expressed in the format HH:mm most of the time.Ī time zone is a geographical region where all people observe a legally mandated standard time.Ī time zone usually has more than one offset from UTC due to daylight saving time. Moment().add(1.5, 'quarters') = moment().add(4.5, 'months') = moment().add(5, 'months')įrequently, people are confused about the difference between time zones and UTC offsets.Ī UTC offset is a value that represents how far a particular date and time is from UTC. Quarters and years are converted to months, and then absolute value/rounded. This means that 1.5 rounds to 2, and -1.5 rounds to -2. Moment.js will accept decimal values and do its best to handle them by rounding to the nearest whole number.Īs of 2.12.0 decimal day and month values use absolute value/round to convert to integers.
Moment(' 13:00:00').add(24, 'hours').format('LLL')ĭue to leap years, one year may not equal 365 days: moment('').add(1, 'year').format('LL')īecause of the variability of duration in day math, Moment's API does not officially support adding or subtracting decimal values for days and larger. Date math can cause some interesting scenarios.ĭue to daylight saving time, one day may not equal 24 hours: //date math Months of course vary in number of days, and due to leap year, years vary in length as well. This is because the amount of time in a day, month, or year is variable.įor example, due to daylight saving time transition, a day may be anywhere between 23 and 25 hours long. In Moment.js time math assumes a linear time scale, just incrementing or decrementing the UTC-based timestamp by the amount of the time units provided.ĭate math does not use a linear time scale, but rather increments or decrements the dates on the calendar. There is a logical difference between time math and date math.
0 kommentar(er)
