crater icon indicating copy to clipboard operation
crater copied to clipboard

Published 20 hours ago • verified publisher icon crater-invoice

Invoice date and due date decreasing by 1 day automatically

Open tamimibrahim17 opened this issue 2 years ago • 5 comments

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

tamimibrahim17 avatar Apr 24 '22 20:04 tamimibrahim17

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

mohitpanjwani avatar Apr 25 '22 12:04 mohitpanjwani

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 image

settings/preferences page image

tamimibrahim17 avatar Apr 25 '22 16:04 tamimibrahim17

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.

mpember avatar May 02 '22 14:05 mpember

Can anyone help with the issue?

tamimibrahim17 avatar May 10 '22 13:05 tamimibrahim17

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

tamimibrahim17 avatar May 16 '22 11:05 tamimibrahim17

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.

arcane47 avatar Feb 03 '23 19:02 arcane47