is there an UTC mode?

[d2bit]

The problem I had is the following. As I'm using CEST timezone the system changes from summer time to winter time (daylight saving time), and I get unexpected results when adding time to my dayjs object.
moment has an UTC mode to set the timezone.

I also found that by default moment does this right
I've attached a failing test. That shows that dayjs is doing different than moment.

test('adding 1 day before changing to daylight summer time', () => {
  const dayBeforeSummerTime = '2018-10-28'

  expect(dayjs(dayBeforeSummerTime).add(1, 'day')).toEqual(moment(dayBeforeSummerTime).add(1, 'day'))
})

I'll be glad to help if I can.
Thanks in advance

[iamkun]

@d2bit

Daylight saving time is new to me, I'll check it.

And for UTC mode, we are working on is, PR #168

Code review or PR is welcome.

[0xsven]

Just stumbled upon this. My date picker has '2018-10-28' twice. xD

My solution for now is:

const nextDay = dayjs('2018-10-28')
          .add(1, 'hours') // to circumvent an issue with dayjs that occurs on 2018-10-28
          .add(1, 'day')
          .format('YYYY-MM-DD')

EDIT: For some reason .add(1, 'second') already does the trick?

[neuronetio]

@0xsven you can't just add an hour to get proper date because sometimes you must add and sometimes you must remove hour depend on summer time or winter time.
On summer clocks are set to -1hour and on winter clocks are set to +1hour.
So sometimes we have (european union) utc+1 and sometimes we have utc+2

[0xsven]

@neuronetio
In my use case (a day picker) I only need the day to be correct.

Also: for some reason, already adding one second solved the problem for me.

[prantlf]

@d2bit, @0xsven, @neuronetio, you initialised the dayjs object with a full local time. You need to remember it, when you're adding or subtracting to/from it.

Your scenario is a "date-only" object. The time part is not relevant. However, JavaScript has no DateOnly or Date.prototype.dateOnly = true. The Date object always includes time and expects the local time zone by default, although you sent only the date part to the constructor by "2018-10-28". You get the time set too, for example to 1:00 in Berlin. If you miss this, you will be in trouble. Knowing this will allow you to use Day.js without problems. I am an EU citizen too :-)

Yes, it may not be obvious, that the time part is always there, when you call dayjs("2018-10-28"). However, this is consistent with new Date("2018-10-28") and thus not confusing and easy to remember.

Day.js could offer an UTC mode, so that if you initialise the dayjs object with UTC, the day will not be converted to the local time zone. But again, remembering how you initialised the object is crucial. Offering a date-only mode would make this scenario clearer.

[ghost]

@neuronetio this lib supports DST since v1.7.7

[iamkun]

DST already supported

[iamkun]

🎉 This issue has been resolved in version 1.8.9 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[iamkun]

Yes, please check.

https://day.js.org/docs/en/parse/utc