Comment 59 for bug 365065

First, thanks for the prompt reply. Im glad the product is still being supported as I like the application.

(In reply to John Ralls from comment #40)
> The transactions aren't invalid, they're just off by a day.

Ok, invalid is a bit strong, but there are some dates that should be on the 1st day of them month that is now the last day if the previous month. This skews any form of monthly reporting, so yeah the transaction is off by a day which makes the report invalid.

>You can edit the date on all of them if it's actually important.

Is there a way to edit them all at once, or do I have to go to each one and increase the day manually? There are literally 100's of them, so to edit each individually, will be a huge task.

> We've just been discussing this in the developer list. We've decided to
> change the posted date timestamp to 1100 UTC regardless of timezone for
> 2.6.14 (2.6.13 release is too close to be sure of getting that change done
> in time). The local adjustment from that will remain the same day everywhere
> except the middle of the Pacific. We'll include a scrub function that
> modifies old data. We'll also make the data-load code able to read date-only
> posted dates; writing those will be in 2.8.

Understood, and glad to hear. What is the time-frame for 2.6.14?

Also, I noticed that this also affects scheduled transactions. I created a few scheduled transactions while I was in New Zealand, scheduled for the 24th of the month. They were created on the 23rd of the month for May and June.