Interesting quirk with using patterns for invoice numbering.

Just noticed a bit of a quirk with patterning invoice numbers, specifically using the date as a prefix.

Currently, I have my numbering pattern setup as {$date:mdy}-{$counter}, and I manually reset the counter every day, while leaving $date to do its thing. I just noticed, however, that on any new quote or invoice, the date used is a day ahead of the current date.

For example, I go to make a new quote today, the 24th. The invoice date shows up as 122516-01 instead of 122416-01. There are no invoices or quotes actually saved today, so I know it hasn’t taken that number already.

Not a major deal since I can manually change the invoice number. But could definitely be annoying for those with a higher volume of invoices.

As always, thanks for your hard work!

Can you check your timezone setting on /settings/localization

It’s set to EST (GMT-5) as is the system itself. However, I did notice that when I use {$date:hi}, it still seems to be using GMT for those variables.

Can you explain what you mean by “as is the system itself”, the timezone should be set to UTC in app/config.php.

To clarify, are you saying the time is right but the day is wrong?

Sorry, meant the server itself (Ubuntu 16.04.1) has the timezone set to GMT/UTC-5. When I use {$date:hi}, the time showing in the invoices is based on GMT, and not the system time.

user@hostname:~$ date
Sun Dec 25 17:24:40 EST 2016

So for example, right now if I were using {$date:hi}-{$counter} it would number the invoice as 2224-01 instead of 1724-01.

It appears that the invoices are getting the wrong date only after 7pm EST, because despite the localization setting or the server timezone setting, the application is pulling the time (and thus the date) as UTC.

Thanks, that’s helpful!

We weren’t applying the timezone when generating the invoice number, I’ve checked in a fix.

https://github.com/invoiceninja/invoiceninja/commit/f65300d10883c0c82eb8e93a70fb472e15bdd208#diff-acd35e0ca01df3c8258726cbecc50cb1L942

That appears to do the trick. Thanks!

Great, thanks for letting us know!

Quick heads-up that the fix didn’t seem to make it into 2.9.3. Going into /app/Models/Account.php and changing the function manually still works, but the updated version didn’t seem to have the fix in it. Double-checked with a fresh download of the zip file to make sure it wasn’t just rsync not copying the files properly.

This fix should be included in v3.0.