Hope it's ok to resurrect this old thread.
I'm having this issue also, but I think I've puzzled out what is happening here. Below is my speculation, based on what I've seen during some experimenting.
When arranging the files for "Sort by Date", Editorial doesn't use the "modified" timestamps as shown in the Mac Finder. Instead, it uses the Dropbox "Last upload" timestamp. You can see this in (iPhone) Editorial by tapping the file name at the top of the note, then the Dropbox icon. I don't know a way to see the "last upload" information on the Mac.
For some people, the "last upload" timestamps are in the same order as the "modified" ones. For example, if you made a folder some time ago, and have been slowly adding and changing files, one by one.
However, if you rename a folder, or duplicate it, the Dropbox client on the Mac re-uploads the files within that folder. It does this file by file. I don't know how it determines the upload ordering of the files, but it isn't by modification date. I've just done some careful testing (macOS 10.12.4, Dropbox client 36.4.22), and renaming a folder or duplicating it essentially randomises the ordering of the files as shown in Editorial. I also suspect from earlier tests that doing the same rename / duplication via the Dropbox website will have the same effect.
Actually, I spent a while trying to write an iOS Dropbox notes app in 2013, using the then-current-but-recently-deceased Dropbox v1 API. I didn't find a way for an iOS app to read the file modification timestamps (as shown in the Finder). That information is stored in Dropbox, as it is synchronised between Macs, but I didn't see it exposed in the API. Perhaps things are different in the newer Dropbox APIs... I haven't looked.
I can think of one way to gain control over this beast, but it isn't elegant. If we have a folder where the "last upload" timestamps of the contained files are in a different order to the "modified" ones (eg because the folder has been duplicated / renamed), it would be possible to write a script to create a new folder, then copy (or move) the files in, one at a time, in "modified" timestamp ordering. I'm not sure how precise the "last upload" timestamps are. Editorial shows them to single minute precision. Perhaps the seconds information is stored but not shown. But assuming it's minute resolution only, then the script would have to wait at least a minute between uploads, to preserve the correct ordering. And worse: the script should really wait until the Dropbox client has finished synchronising before starting the next file upload - and I don't see a way for a script to determine if Dropbox sync is in progress or not.
Hope this makes some kind of sense - apologies, because I'm writing in haste. Best wishes all.
