Database backups: timestamps are month-1/zero-indexed, are not zero padded, and duplicate backups are generated

Describe the Bug

When I upgraded on Saturday, 2026-09-12, the backup file name is db_2026-8-12_20-35-56.sqite

# stat config/db/backups/db_2026-8-12_20-35-56.sqlite 
  File: config/db/backups/db_2026-8-12_20-35-56.sqlite
  Size: 21716992  	Blocks: 42416      IO Block: 4096   regular file
Device: 8,1	Inode: 529585      Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2026-09-15 12:30:47.995058492 -0400
Modify: 2026-09-12 20:35:58.479893142 -0400
Change: 2026-09-12 20:35:58.479893142 -0400
 Birth: 2026-09-12 20:35:56.983870134 -0400

Furthermore, there are two non-identical backups, despite upgrading once:

.rw-r--r-- 22M 12 Sep 20:35 db_2026-8-12_20-35-56.sqlite
.rw-r--r-- 22M 12 Sep 20:36 db_2026-8-12_20-36-2.sqlite

# diff db_2026-8-12_20-3*
Binary files db_2026-8-12_20-35-56.sqlite and db_2026-8-12_20-36-2.sqlite differ

# stat db_2026-8-12_20-36-2.sqlite 
  File: db_2026-8-12_20-36-2.sqlite
  Size: 21716992  	Blocks: 42416      IO Block: 4096   regular file
Device: 8,1	Inode: 529753      Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2026-09-15 12:30:47.719054280 -0400
Modify: 2026-09-12 20:36:03.308967432 -0400
Change: 2026-09-12 20:36:03.308967432 -0400
 Birth: 2026-09-12 20:36:02.985962465 -0400

Another user also confirmed this observation and that they have a db_2026-0-23_20-25-49.sqlite created in January.

To the best of my knowledge, no Gregorian-based civil dating system on the planet uses zero-indexed months so this is inherently confusing, which is obviously absolutely not what you want to deal with if you ever need to actually use one of these backups. Further complicating this is: there are two backups for one upgrade, if I need to use one of these backups, which one of them do I use?

Also, I don't know how these timestamps are being generated (though the zero index hints at JS/Java, see below?), but the lack of zero-padding the digits is just anathema to me (e.g., look at my Grateful Dead concert recordings, bootlegs AND label releases). This is, however, less concerning since there shouldn't be a sorting issue that matters.

Environment

• OS Type & Version: Ubuntu 24.04
• Pangolin Version: 1.20.x > 1.22.2, though it seems to go back much further than that.
• Edition (Community or Enterprise): ee

To Reproduce

Upgrade Pangolin without backups disabled, review filenames of backups.

AI Disclosure

Yeah, I checked with ChatGPT to see if somehow I just never ran across this as a convention before (despite actually being on the ISO-8601 Wikipedia page last week and my clear interest in timestamps given my contribution to this project).

Expected Behavior

zero-padded, normal (i.e., 1-indexed) Gregorian month timestamps for file names in an ISO-8601 format, similar to that produced by GNU date -Is.