4 ms·

Can someone explain how this will affect me? Will my code break because the server is down or is this more of an issue for populating the time zone data for OS

by varikin 15y ago

Can someone explain how this will affect me? Will my code break because the server is down or is this more of an issue for populating the time zone data for OS and language libraries?

ra 15y ago
Essentially, your OS provider, if it uses this database, will likely choose to cease distributing tzdata until the disputed data is removed / replaced. Very short term, no big deal. Longer term, it could be a big deal if this leads to fragmentation and inconsistencies in tzdata.
dsl 15y ago
Your operating system (and likely your programming language too) have local copies. You just won't get updates until this is all sorted out.
apaprocki 15y ago
This would only affect people right now if a timezone change was made by some government somewhere in the world and a change needed to be made to the database files and published so all the software which embeds it could update. If the site remains down, mailing list members would simply discuss and post the change that needed to be made and software embedding the files and OS vendors would need to update manually. tl;dr Nothing is going to change anytime soon.
damoncali 15y ago
It won't.
jholman 15y ago
Your code won't break. And you probably won't even have any difficulty populating the database on new installs, since your OS provider is probably mirroring the current database. But there are "between 20 and 100" changes to the worldwide timezone-set per year. So three weeks from now, someone's gonna change their timezone rules, effective perhaps 2013. Maybe it'll be Bolivia. And then three weeks later, someone else, maybe some part of Indiana. Then three weeks later, maybe a civil war in some ex-SSR or something finally resolves, and the two different halves end up using different time zone plans (one of them uses DST, the other doesn't, and neither of them use the USSR regime they had last year). So now a year passes, it's 2012, what're you doing? Is your software using a database that's a year (and maybe 50 events) out of date? Or did you hand-maintain it, because you care about Indiana, and you got 10 of the 50 events? Or maybe you used the Debian fork of tzdata? And what am _I_ doing? Probably not the same thing as you. And now when my software and your software try to interoperate (maybe our iCal calendaring, maybe our enterprise order management integration bus service routing frameworks, maybe we just want to agree when your mother's flight will land), guess what. Sooner or later a relevant event happens in one of the altered timezones, and someone misses a flight, and we get a very very difficult-to-track-down bug. Actually, it's not that terrible, as long as every time event you care about takes place in a big important time-jurisdiction that'll be maintained by every tzdata fork that every software you care about will use. Which I guess could theoretically apply to me or you. I don't actually care about Indiana, so I don't care if time events that take place there don't synchronize.
- morpher 15y ago
  If we agree that most OS vendors will probably ignore the copyright claim and keep using the current database, then one could put any newer updates into a "patch database", which clearly would not be under any prior copyright (and could be easily made available to everyone as the old database was). So, I don't really buy your parable about how this will only affect future changes. If tzdata "forks", it will be between what old (possibly copyrighted) data is included.
  - varikin 15y ago
    So, in the end, the people that need to worry about this issue know they need to worry about this issue.
  - jholman 15y ago
    Well, on the one hand, I agree with you about one source of forks being old data, although at least this is a relatively simple fork: those who excise the allegedly-infringing parts of the database, and those who do not. On the other hand, I think you are completely groundless in your assertion that it can't fork over future changes. There could be multiple patch databases with disjoint changesets in them, with different software using different databases. And it's not _my_ parable. It's my rephrasing of the FA, and the comments by the FA's author in his own comments thread.

by varikin 15y ago

Can someone explain how this will affect me? Will my code break because the server is down or is this more of an issue for populating the time zone data for OS and language libraries?

ra 15y ago

Essentially, your OS provider, if it uses this database, will likely choose to cease distributing tzdata until the disputed data is removed / replaced. Very short term, no big deal. Longer term, it could be a big deal if this leads to fragmentation and inconsistencies in tzdata.

dsl 15y ago

Your operating system (and likely your programming language too) have local copies. You just won't get updates until this is all sorted out.

apaprocki 15y ago

This would only affect people right now if a timezone change was made by some government somewhere in the world and a change needed to be made to the database files and published so all the software which embeds it could update. If the site remains down, mailing list members would simply discuss and post the change that needed to be made and software embedding the files and OS vendors would need to update manually. tl;dr Nothing is going to change anytime soon.

damoncali 15y ago

It won't.

jholman 15y ago

Your code won't break. And you probably won't even have any difficulty populating the database on new installs, since your OS provider is probably mirroring the current database. But there are "between 20 and 100" changes to the worldwide timezone-set per year. So three weeks from now, someone's gonna change their timezone rules, effective perhaps 2013. Maybe it'll be Bolivia. And then three weeks later, someone else, maybe some part of Indiana. Then three weeks later, maybe a civil war in some ex-SSR or something finally resolves, and the two different halves end up using different time zone plans (one of them uses DST, the other doesn't, and neither of them use the USSR regime they had last year). So now a year passes, it's 2012, what're you doing? Is your software using a database that's a year (and maybe 50 events) out of date? Or did you hand-maintain it, because you care about Indiana, and you got 10 of the 50 events? Or maybe you used the Debian fork of tzdata? And what am _I_ doing? Probably not the same thing as you. And now when my software and your software try to interoperate (maybe our iCal calendaring, maybe our enterprise order management integration bus service routing frameworks, maybe we just want to agree when your mother's flight will land), guess what. Sooner or later a relevant event happens in one of the altered timezones, and someone misses a flight, and we get a very very difficult-to-track-down bug. Actually, it's not that terrible, as long as every time event you care about takes place in a big important time-jurisdiction that'll be maintained by every tzdata fork that every software you care about will use. Which I guess could theoretically apply to me or you. I don't actually care about Indiana, so I don't care if time events that take place there don't synchronize.

morpher 15y ago
If we agree that most OS vendors will probably ignore the copyright claim and keep using the current database, then one could put any newer updates into a "patch database", which clearly would not be under any prior copyright (and could be easily made available to everyone as the old database was). So, I don't really buy your parable about how this will only affect future changes. If tzdata "forks", it will be between what old (possibly copyrighted) data is included.
- varikin 15y ago
  So, in the end, the people that need to worry about this issue know they need to worry about this issue.
- jholman 15y ago
  Well, on the one hand, I agree with you about one source of forks being old data, although at least this is a relatively simple fork: those who excise the allegedly-infringing parts of the database, and those who do not. On the other hand, I think you are completely groundless in your assertion that it can't fork over future changes. There could be multiple patch databases with disjoint changesets in them, with different software using different databases. And it's not _my_ parable. It's my rephrasing of the FA, and the comments by the FA's author in his own comments thread.