Recurring Invoices created with "yesterday's" date when timezone is UTC++

[semiligneous]

Issue filing prerequisites

• I've checked the documentation.
• I've looked for similar issues both Open and Closed.
• I've tried clearing both cache and cookies in my browser or tried opening the app in the Incognito/InPrivate window.

Describe the bug

Using Invoiceshelf via Docker. On most recent version 2.1.1.

I am based in Australia and have my timezone set in compose:

      - PHP_TZ=Australia/Sydney
      - TIMEZONE=Australia/Sydney

I have a number of recurring invoices set up, with the cron task set as:

On the first day of every month at 00:00

the invoices get created, but when I check the content the next morning on 1st October, the invoice date is 30th September (and they were all 31st August last month in September, and before that).

Also, I use a YY-MM date variable in the invoice name, and this month's invoices are all named with 25-09 (for 2025-September) as opposed to 25-10 for October.

I expect them to be using the current month as of the first day of every month at 00:00 - October in this case, so the invoice date should be 1st October and they should all have 25-10 in the name.

My hunch, having suffered timezone issues frequently (living here in ‘the future’ ) is that there is some part of the recurring invoice job that is somehow running on UTC (or maybe another timezone that is behind Australia time) and another part running on Australia time. For example, perhaps the cron job runs based on Australia time and runs at 00:00 1st October as expected, but the part of the code that fetches / creates any date fields within that job, and uses them in 'invoice name' and 'invoice date', and others, is maybe not respecting my timezone, instead using UTC (or some other hard coded default) and fetches like ‘right now today, it’s 1pm on 30th September UTC’ - leading to incorrect outcome.

Steps to Reproduce the issue

This should be reproducible - although waiting for a genuine new month to come around would be slow, so probably need to adjust system time, which may get messy.

Perhaps the same issue can be observed by setting TZ to eg Sydney, and simply generating a recurring invoice every day at 00:00 and looking at the resultant "invoice date" to see if it is happening correctly. My suspicion is that the resultant invoice will be created on Date X, but have an Invoice Date value of "Date X-1"

Expected behaviour

the part of the system that inserts date and months into the invoice should respect my local time zone.

Actual behaviour

it does not, it seems to be a timezone that hasn't yet switched to the next day (or month)

Docker

• App running in Docker Container.
• Docker container running behind Reverse proxy.

InvoiceShelf version

2.2.1

PHP version

whatever is shipping in latest image

Database type

sqlite

Database version

latest

Web Browser

not important here, any/all - its app-level

Server OS

Ubuntu - but it's docker

Reverse-proxy logs

Laravel/PHP logs

[rihards-simanovics]

I've set the timezone on my test instance and will report if I see the same behaviour.

[rihards-simanovics]

daily @2:30am created it fine, I'll do a daily at midnight.

[semiligneous]

@rihards-simanovics - I have just set up a new test company, and a recurring invoice using "Every day at midnight". I set it up at about 11.30pm on Sunday 12th October. My timezone is set as before in docker compose.

At 00:00 on 13th October, the job ran and sent me an invoice. You can see in screenshot the email arrived to me at 00:00 13th October as expected.

However, open the PDF attachment and the "Invoice Date" is 12th October - which is incorrect, it should be 13th.

[rihards-simanovics]

You need to open docker exec -it <containerNameOrID> /bin/bash to the container and inside the interactive shell run timedatectl and date commands. Could you check the time output and compare it with the local time adjusted for any time zone differences? Also check for the correct time in the BIOS/UEFI.

Other than that, I'm afraid there isn't much more I can do, as the debugging utility that used to be bundled with the app is not responding to activation in my test environment. The only thing I can suggest is to set the corn time to 30 0 * * *, which is equivalent to 00:30 am, and see if this works.

[semiligneous]

@rihards-simanovics

root@d97012fc46da:/var/www/html/InvoiceShelf# timedatectl

System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down

root@d97012fc46da:/var/www/html/InvoiceShelf# date

Mon Oct 13 00:43:18 UTC 2025

So yes, the container itself is indeed running in UTC

But the app (invoiceshelf) itself offers timezone support in the configuration, and that support DOES work for the scheduler for recurring tasks - the invoice was generated at 00:00 local time, which is good.

However, it seems that my suspicion was correct that the job itself is looking at the container's system date as opposed to the date based on the timezone set in configuration.

I looked into how docker compose timezone info is supposed to be set (because ln -sf /usr/share/zoneinfo/Australia/Sydney /etc/localtime won't persist a container restart) and discovered that it is simply done as an environment variable:

	environment:
			- "TZ=Australia/Sydney"

I looked at the my compose file and I have:

      - PHP_TZ=Australia/Sydney
      - TIMEZONE=Australia/Sydney

I don't know where I got these variable names from.... They don't seem to be present in the current example compose.yaml files...!

But one of them at least seems to be working because the recurring invoice task DID start in my timezone!

I can only find reference to "TIMEZONE=" in an example .env file:

InvoiceShelf/.env.example

Line 6 in 935fe06

APP_TIMEZONE=UTC

APP_TIMEZONE=UTC

So yeah, I'm a bit confused what the correct way to set timezones is supposed to be!

For now, I have added TZ= to mine so I have:

    environment:
      - PHP_TZ=Australia/Sydney
      - TIMEZONE=Australia/Sydney
      - TZ=Australia/Sydney

The date in container itself is now in my TZ:

~/docker/invoiceshelf$ docker exec -it invoiceshelf /bin/bash

root@9e577517b650:/var/www/html/InvoiceShelf# date

Mon Oct 13 12:14:44 AEDT 2025

And I will see if this single addition makes the invoice date correct when it runs tonight at 00:00!

Thanks for your help looking into it.

[rihards-simanovics]

As with anything international, time zones can be a real pain. I'll open a new issue on the Docker side to point out the missing TZ env var, which is likely used by he container itself to set the container TimeZone.

[rihards-simanovics]

I'm going to mark this as fixed since it's just an extra env var that needs to be added.