[tz] changes to the TZ database over versions
keisial at gmail.com
Sun Jun 1 18:01:21 UTC 2014
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
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
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tz