> Matching geo data to a timezone is a bit fuzzy. On
the
> other hand, you state that correct calculation is
critical.
We’re working with old protocols that don’t include TZ
information in the data that is sent to us, so we have to get thet TZ info
through geo mapping tables.
We’ve been looking at geopostcodes.com.
We’d like it to be as correct as possible, but realize it’s
not possible to cover everything.
Eg. 2014-10-26T02:05:00 may refer to
2014-10-26T02:05:00.000+02:00 or 2014-10-26T02:05:00.000+01:00
> Now I'm thinking that perhaps you aren't working on historic
>
records but with future ones, in which case it's very likely that
> tz
will be right (but in that case why not store them in UTC directly?)
Our data is all about real-time events, but when reports need to be
regenerated for some reason in the future, they will be historic. Hence
the questions about tz versions.
Cheers,
Joris