startOf not working when the timezone is set to UTC+0:00

[anmol5varma]

Describe the bug
When I set the timezone to Africa/Accra(UTC+00:00), the startOf function starts behaving weirdly.

Code

import './App.css';
import dayjs from 'dayjs';
import timezone from 'dayjs/plugin/timezone';
import utc from 'dayjs/plugin/utc';
import { useState } from 'react';

dayjs.extend(timezone);
dayjs.extend(utc);


function App() {
  const renderTime = (tz) => {
    const inputDate = dayjs("2023-07-10 09:00:00").tz("Asia/Calcutta")
    dayjs.tz.setDefault(tz)
    const now = dayjs.tz(inputDate)
    const date = now.format();
    const startDate = now.startOf('d').format();
    return {
      date,
      startDate
    }
  };

  const {date, startDate} = renderTime('Africa/Accra')
  const {date: date1, startDate: startDate1} = renderTime('Asia/Calcutta')
 
  return (
    <div className="App">
      <p>Current time: {date}</p>
      <p>Start time: {startDate}</p>
      <hr/>
      <p>Current time: {date1}</p>
      <p>Start time: {startDate1}</p>
    </div>
  );
}

export default App;

Expected behavior
The Start time in case of 'Africa/Accra' should be 2023-07-10T00:00:00Z and not 2023-07-09T18:30:00Z

Information

• Day.js Version 1.11.7
• OS: 13.4.1
• Browser: Version 114.0.5735.198 (Official Build) (arm64)
• Time zone: GMT+05:30

[anmol5varma]

Any updates?

[anmol5varma]

To add more clarity on this.
The following test case fails in the current dayjs package.

it('UTC and startOfDay', () => {
  const date = dayjs('2023-07-10 09:00:00').tz('Asia/Calcutta')
  dayjs.tz.setDefault('Africa/Accra')
  const now = dayjs.tz(date)
  expect(now.startOf('d').format()).toBe('2023-07-10T00:00:00Z')
})

It fails with the following error message

● UTC and startOfDay

expect(received).toBe(expected) // Object.is equality

Expected value to be:
  "2023-07-10T00:00:00Z"
Received:
  "2023-07-09T18:30:00Z"

My machine timezone is UTC+05:30. I think it doing a startOf('d') based on my timezone and then converting it to UTC+0:00. @iamkun I see that you are actively resolving issues on the repo. Can you please help on this?

[aivanov-noveo]

The same goes for hour, add(1, 'day') and maybe others too. @michelengelen I hope this PR will fix them too.

[michelengelen]

The same goes for hour, add(1, 'day') and maybe others too. @michelengelen I hope this PR will fix them too.

@aivanov-noveo what exactly is wrong with hour and add? I cannot find any inconsistencies here. Could you elaborate a bit?

[aivanov-noveo]

@michelengelen here is a bit of code:

function startOf(date: Dayjs): Dayjs {
  return date.hour(0).minute(0).second(0).millisecond(0);
}

  const winterLondonStr = '2023-11-29T10:00:00.000Z'; // UTC+00:00
  const summerLondonStr = '2023-09-29T10:00:00.000Z';// UTC+01:00
  const londonTz = 'Europe/London';
  const winter = dayjs(winterLondonStr);
  const winterLondon = winter.tz(londonTz);
  const summer = dayjs(summerLondonStr);
  const summerLondon = summer.tz(londonTz);

  const winterLondonPlus = winterLondon.add(1, 'day');
  console.info(
    'winterLondonPlus',
    winterLondonPlus.format(),
    winterLondonPlus.toISOString(),
  );
  const winterLondonStartOf = startOf(winterLondon);
  console.info(
    'startOf(winterLondon)',
    winterLondonStartOf.format(),
    winterLondonStartOf.toISOString(),
  );

  const summerLondonPlus = summerLondon.add(1, 'day');
  console.info(
    'summerLondonPlus',
    summerLondonPlus.format(),
    summerLondonPlus.toISOString(),
  );
  const summerLondonStartOf = startOf(summerLondon);
  console.info(
    'startOf(summerLondon)',
    summerLondonStartOf.format(),
    summerLondonStartOf.toISOString(),
  );

the result (winter times are incorrect, summer ones are correct), my local timezone offset is +04:00

winterLondonPlus 2023-11-30T06:00:00Z 2023-11-30T10:00:00.000Z
startOf(winterLondon) 2023-11-29T00:00:00Z 2023-11-29T04:00:00.000Z
summerLondonPlus 2023-09-30T11:00:00+01:00 2023-09-30T10:00:00.000Z
startOf(summerLondon) 2023-09-29T00:00:00+01:00 2023-09-28T23:00:00.000Z

[michelengelen]

@aivanov-noveo this is a different problem and I think that will be resolved when #2118 gets merged.

This is what I got from the short script you mentioned before:

---
winterLondonPlus
2023-11-02T10:00:00Z
2023-11-02T10:00:00.000Z
---
startOf(winterLondon)
2023-11-01T00:00:00Z
2023-11-01T00:00:00.000Z
---
summerLondonPlus
2023-10-01T11:00:00+01:00
2023-10-01T10:00:00.000Z
---
startOf(summerLondon)
2023-09-01T00:00:00+01:00
2023-08-31T23:00:00.000Z
---

I hope @iamkun will merge both of the PRs soonish, so the issues can e solved with it!

Thanks for taking the time to raise this issue as well.