The DateChanger plugin allows for one date selection at the time of the creation; once the post has been created you cannot choose another date for that post.
The question in why.
While it is technically possible changing the date of a post, it is quite complicated, and this is linked to the way FlatPress lays files on the file system (which was inherited from SimplePHPBlog, and which sounded a good idea at the time — I still think it is, since its features make it human intelligible).
Each post is contained in a file POST-ID.txt, which contains, along with the actual text of your post, other pieces of information such as the date; the date is stored in a field called the TIMESTAMP.
Now, POST-ID it is defined in a form which reflects the contained TIMESTAMP field.
Each file is in fact named entryYYMMDD-hhmmss.txt (where YY stands for a two-digit year, MM month, DD day, hh hours, mm minutes, ss seconds), and it is saved under the directory tree
So, say, a post written on January, 1st 2010, saved at 7 o’ clock would be
also, any comment associated to that post would be in a directory called
Each post-id/timestamp is also stored in several indices, one global, and one for each category under which the post has been filed.
Now, suppose you want to change date to that one post, and suppose you have to move it to February, 2nd.
1) You have to update the contained TIMESTAMP field
2) You have to move the file; which means renaming to the new ID and actually move it to another directory tree (in this case fp-content/10/02/); directory tree which might not exist, so you’d add to this creating those directories (also if /10/01 became empty FlatPress would even delete 01! so, sum this one up, too)
3) You have to update each associated index: which translates into deleting the old ID associated to this post, and then add back the new ID.
I believe you can see how many things can fail in the process.
If the ID had no associated meaning (the date/timestamp) you would just have to update the contents and the indices.
Unfortunately, this is not the case.