Invoice date and due date decreasing by 1 day automatically

[tamimibrahim17]

Describe the bug Invoice date and due date decrease by 1 day automatically from frontend after pressing save invoice button from invoice edit page.

Expected behavior Invoice date and due date should not be changed automatically unless user change date.

Please complete the following information:

• Crater version: 6.0.6
• PHP version: 7.4.28
• Database type and version: sqlite

Optional info

• OS: Ubuntu
• Browser: chrome

[mohitpanjwani]

Hey @tamimibrahim17, did you update the timezone on the config or env file directly?

[tamimibrahim17]

Hi @mohitpanjwani Thanks for the reply. No I did not change the timezone manually in .env or config/app.php file. But in our hosted application we did changed the timezone in settings/preferences page.

config/app.php file

settings/preferences page

[mpember]

I have experienced the same issue. If you create a new invoice, the date is correct. However, each time you open that draft, it steps back a day for both the invoice and due dates.

I can set the timezone via the config/app.php settings. I have the same timezone set in the preferences section of the web interface. I have no timezone-related settings in the .env file. I am in UTC+10 at the moment.

When the invoice is loaded for editing, the date value is in the following format: 2022-04-29T14:00:00.000000Z If the date is not changed, it remains in this format. If it is modified, or you simply select the same date from the picker, the data submitted in the PUT request has the dates in the following format: 2022-04-29. The updated invoice then loads with the date as: 2022-04-28T14:00:00.000000Z

This suggests that the problem is caused by a rounding issue for anyone who is east of UTC and west of the international date line. It will be masked for anyone west of UTC because the offset would be added to the date and then resolved when the time is ignored.

[tamimibrahim17]

Can anyone help with the issue?

[tamimibrahim17]

Hello @mohitpanjwani can you please give here any update regarding this issue?

[arcane47]

This suggests that the problem is caused by a rounding issue for anyone who is east of UTC and west of the international date line. It will be masked for anyone west of UTC because the offset would be added to the date and then resolved when the time is ignored.

West of UTC here, and still the same problem.