It is impossible to keep a UNIX "universal anchor" for days (LocalDate.now().toEpochDay()) like the way UNIX-time does, since the days of ALL the different regions heavily overlap on top of each other.
With "universal anchor" I mean a value that is kept constant (UTC) across the entire globe, and that can be properly parsed on each device simply by specifying its ZoneId offset.
This means that, if a user from Sydney enters a value in a database which is indexing data based on the epochDay() of the device, His entry would be seen in the US as appearing the day after.
So, one solution I've been thinking of is to assign a SPECIFIC region to the branch, maybe to assign to it the ZoneId of the region from the user that created the branch (the administrator).
If the admin moves to a different region, the branch asks permission to reset the value.
So that when the Sydney user, is granted permission to write in the branch, he is made aware that they would be working BASED on the specific region of the admin, a US region.
Now the Australian user could figure his offset from the admin, parsing the values correctly to his time at the moment of reading from DB, while in reality his entries are being written to "the past", So, the Administrator would have a concrete and real view of the data.
This is not perfect since days overlap... but while the Australian would still NOT GET a precise day (one that encompasses from HIS 00:00 am to his 00:00 pm) at least his device could add a day (24hours) manually to not make it so evident.
Since the UNIX-time of the Sydney and NY users are the same, the ONLY thing that the Australian user would need to create from scratch is the .epochDay() based on the region specified in the DB branch... currentTimeMillis() and epochSeconds are still the same...
Is this a proper solution for denormalized databases that index on a 'by-day' basis?