On 01/06/14 18:03, Joris Van den Bogaert wrote:

Hi Angel,

> 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.

I would evaluate switching the software to start reporting in UTC after some epoch (2015-01-01? 2014-07-01?).

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

Right. Tha local time alone is ambiguous.
Although I was thinking in cases of "We are not sure if this Valley uses the timezone of the town 10 Km North or the one 8 Km South"
As you now clarified that you are dealing with «recent» events, that's unlikely to happen. Actually, you may be able to tag each source with the tzid.

> 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.

If you convert them properly to UTC today, then you won't need them regenerated in the future. There is a big difference between processing what happened 40 years ago and what is happening right now. Nowadays, you can easily know your offset.

Cheers