On Wed, Apr 27, 2016, at 12:21, Jon Skeet wrote:
I'd say those cons are pretty significant - I find it very significantly harder to read than the format I've propsed. I'm also confused by your "pro" that it doesn't depend on any implementation details, but it really *exposes* the implementation details in naming ("isdst" and "gmtoff" for example, along with the mysterious huge numeric values).
isdst is standard C. gmtoff is a common extension. My point is that it doesn't actually parse the internal structures of the timezone files, it simply calls localtime over and over with different values, and so can be used even with a radically different implementation of the C functions, or against POSIX timezone strings, etc.
The aim is to have a format which is easy and natural to generate on *multiple* platforms, so that authors of other code parsing the data can validate against it. That would be a *very* unnatural format to generate from .NET with either Noda Time or TimeZoneInfo, or from Java 7, Java 8 or Joda Time.