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
