Tim Uckun <timuckun@gmail.com> writes:
> 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.
>
I wouldn't do it that way. I would have all timestamps in UTC. If the
location of the client is necessary for some business process, then I
would explicitly record that information rather than rely on time zone
data to derive location.
I've also found having all timestamps in UTC makes any analysis and bug
tracing much easier. Nothing worse then when you need to look at
timestamps from different components of your architecture spread over
different time zones where you also have to convert the timestamps to a
common/consistent time zone for comparison and sequencing purposes.