29908 2016-10-04 15:27:09 +0000 [FO31] Olson timezone reference 2016-12-16 19:55:17 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Functions and Operators 3.1 Candidate Recommendation PC Windows NT CLOSED FIXED P2 minor --- 1 abel.braaksma mike public-qt-comments oldest_to_newest 127648 0 abel.braaksma 2016-10-04 15:27:09 +0000 The Olson timezone link points to something odd, which hardly seems authoritative (anymore): http://www.twinsun.com/tz/tz-link.htm. Since 2011, the TZ database is maintained by IANA, which took it over after a lawsuit and some other issues: http://www.iana.org/time-zones. Also, the term "Olson timezone" seems to have been changed: "IANA Timezone Database" (source: https://en.wikipedia.org/wiki/Tz_database), which seems more appropriate than using the original founder's name. Part of ACTION A-654-11. 127649 1 abel.braaksma 2016-10-04 15:32:34 +0000 In addition, we say "It is ·implementation-defined· which version of the database is used.". I think this is unclear, as the current link, nor the new link, clearly speaks of versions, unless what is meant is any of the historical databases? Perhaps we can change this to, say, "It is implementation-defined whether a historical version, or the current version, as a whole or in parts, is supported." (stressing that I don't think we mean to have to support either all, or nothing, or do we?). 127857 2 mike 2016-10-19 14:39:05 +0000 I have changed the reference to "The IANA Timezone Database" as suggested. I don't think I understand why the statement about versioning is problematic. The web site identifies the current version as 2016g, released 2016-09-28. So the database is clearly versioned, and implementations must have a policy on what version they use. (In our case, it's whatever version your installed JDK uses...) 127878 3 abel.braaksma 2016-10-20 11:50:51 +0000 (In reply to Michael Kay from comment #2) > The web site identifies the current version as 2016g, released > 2016-09-28. So the database is clearly versioned, and implementations must > have a policy on what version they use. (In our case, it's whatever version > your installed JDK uses...) I must have missed that. Let's leave it as it is then, sounds good to me.