> The root of the collisions is the arbitrary number of extended digits > (which may be 0, so you could have -0101, now is that the year 102 > BC, or January in 2001? The extended formats also collide internally, > i.e. what is the date +1985? Is it a century or a year?
That document is a disaster for any software wanting to parse it's formats... infact a human can't parse most of those formats without external information. > The choices for resolving this are to: > 1) Never allow an extended representation (even for +s which can't > collide externally) unless the user tells us to use it and > specifies the digits > 2) Use the ordering above to break ties When I started writing DateTime::Format::ISO8601 I was using the ordering method. Although I think it maybe necessary to to use both 1 and 2. Someday I may finish this module - what name are you planning on using? > I am leaning towards choice 2 for this, but things are not completely > dire since I plan to allow the user of the module to pick which > categories of formats to allow (and to specify how many digits are in > an extended date). It'll probably take a bunch of wired tweaks to get the right behavior. Good luck :) Cheers, -J --
