On 22/09/21 20:11, Tim Uckun wrote:
I'll add another layer of complication.
You have a database server hosted in Australia, and that's also where
your web server and api server is. You have customers all over the
world though so you set up additional API servers in Europe, USA,
Japan etc.
A korean user will fetch you single page app as static HTML from S3
with cloudfront. It will hit your japanese API server, which will
fetch the data from your japanese read only replica with the master
being in Australia.
The master DB writes the records has to know your end user is in
Korea somehow so you have to carry that time zone all the way across
those tiers.
To me the ideal solution would be to have a compound object which has
the time zone in it. This object gets passed through the tiers and end
up at the database where it's stored.
[...]
Please don't top post! Bottom post like I am.
I imagine the compound object, call it timestamporigin (timestampo?))
would have 2 components:
1. GMT time
2. Offset hours & minutes
3. client time zone code
This was means:
1. you could calculate accurate time differences even between 2
timestampo's regardless of which time zone they came from
2. you know the correct local time it was made
3. you know the time zone it came from
4. it would still be correct even if the machine's, or the server's,
time zone file was updated and the changes applied retroactively.
Cheers,
Gavin
