IANA time zone database - release management: Difference between revisions
No edit summary |
No edit summary |
||
| Line 9: | Line 9: | ||
September-October | September-October | ||
---- | ---- | ||
gunther vermeir 2013-09-19 11:02:39 http://mm.icann.org/pipermail/tz/2013-September/020292.html | gunther vermeir 2013-09-19 11:02:39 UTC http://mm.icann.org/pipermail/tz/2013-September/020292.html | ||
it would be good to have a public update that keep things more or less | it would be good to have a public update that keep things more or less | ||
as they are until | as they are until | ||
* there is a consensus about what to change exactly | * there is a consensus about what to change exactly | ||
* there is time to test if more radical changes actually break things | * there is time to test if more radical changes actually break things | ||
Revision as of 2013-09-19T13:43:08
IANA time zone database
time zone acronyms |
zone changes |
cutoff date |
pre-1970 |
uninhabited territory |
file - backward
release management |
bugs |
proposals |
censorship
Andy Henninger 2013-09-18 21:36:41 UTC http://mm.icann.org/pipermail/tz/2013-September/020282.html
In an ideal world, from my perspective, changes that affect the present or near future time would be kept separate from other changes, and have a fast-track release process. And perhaps substantial cleanup and historical data updates would be kept away from the busy times in March-April, and September-October
gunther vermeir 2013-09-19 11:02:39 UTC http://mm.icann.org/pipermail/tz/2013-September/020292.html it would be good to have a public update that keep things more or less as they are until
- there is a consensus about what to change exactly
- there is time to test if more radical changes actually break things