Re: ISO 8601 is eeeevil!

2003-06-20 Thread Joshua Hoblitt
I was thinking about DateTime::Format::ISO8601... unless you have laid claim to it. This is the namespace I started on in March but whatever does ISO8601 should go there. Perhaps one of you should add it to the CVS server as-is and both work on it? I haven't worked on this since the

Re: ISO 8601 is eeeevil!

2003-06-20 Thread Joshua Hoblitt
I haven't worked on this since the beginning of April. I believe this is most of the date specifications - not including the week formats. Week and UTC offset handling, time formats, and date + time formats are left (actually shouldn't be that bad). Although I don't remember why I

Re: ISO 8601 is eeeevil!

2003-06-20 Thread Ben Bennett
I will try to have something usable by tomorrow... I made some decent progress last night. -ben On Fri, Jun 20, 2003 at 01:08:13PM +1000, Iain Truskett wrote: * Ben Bennett ([EMAIL PROTECTED]) [20 Jun 2003 12:59]: On Wed, Jun 18, 2003 at 06:42:06PM -1000, Joshua Hoblitt wrote:

Re: ISO 8601 is eeeevil!

2003-06-20 Thread Iain Truskett
* Ben Bennett ([EMAIL PROTECTED]) [20 Jun 2003 21:57]: I will try to have something usable by tomorrow... I made some decent progress last night. Excellent. May I suggest you don't worry too much about usable? Once you get it out there (or, rather, in there to CVS) other people can help work

RE: ISO 8601 is eeeevil!

2003-06-19 Thread Peter J. Acklam
Ben Bennett [EMAIL PROTECTED] wrote: Ok. So ISO8601:2000 defines all sorts of things, some of which are impossible to distinguish from one another without outside information: +yMMDD Extended complete year +yDDD Extended ordinal day in year No, these are called expanded, not

RE: ISO 8601 is eeeevil!

2003-06-19 Thread Bruce Van Allen
On Thursday, June 19, 2003 Jerry Wilcox wrote: At 4:25 PM +0200 6/19/03, Peter J. Acklam wrote: Anyway, I see your point, but I don't agree. There is only need for an agreement when ambiguous formats are used, which is a good thing since ambiguous date formats are, as everyone here knows, a big

Re: ISO 8601 is eeeevil!

2003-06-19 Thread Ben Bennett
Well that was always my intention. I plan to allow the caller to specify what exact rules to use since the spec basically allows very little unless the parties agree. However, I think that the default format (if nothing was specified) should allow for parsing of common ISO8601 formats. This

Re: ISO 8601 is eeeevil!

2003-06-19 Thread Peter J. Acklam
John Peacock [EMAIL PROTECTED] wrote: When I made a very simple attempt at this back in January, I limited myself to the most basic format: if ( @date = ( $val =~ /(\d\d\d\d) # year with century -? # possible hyphen (\d\d)

Re: ISO 8601 is eeeevil!

2003-06-19 Thread Ben Bennett
On Wed, Jun 18, 2003 at 06:42:06PM -1000, Joshua Hoblitt wrote: [...] 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

Re: ISO 8601 is eeeevil!

2003-06-19 Thread Joshua Hoblitt
I don't know if I will manage to finish this thing, it is a bit of a monster. Thats what happened to me. :) -J --

ISO 8601 is eeeevil!

2003-06-18 Thread Ben Bennett
Ok. So ISO8601:2000 defines all sorts of things, some of which are impossible to distinguish from one another without outside information: +yMMDD Extended complete year +yDDD Extended ordinal day in year -YYMM Year and month in implied century -DDDOrdinal day in implied

Re: ISO 8601 is eeeevil!

2003-06-18 Thread Joshua Hoblitt
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