[tz] changes to the TZ database over versions

[Ángel González]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20140601/e2ae23f1/attachment.html>