I agree with the time subpackage. Then, we can put time.calendar if we have multiple calendar classes, time.date if we have multiple date classes.
I think we should stick with the existing syntax for using SimpleDateFormat since that is what people already know, I can't think of a powerful reason to not stick with it. I like the preset patterns in DateUtils like ISO8601_TIME_PATTERN, however, I also wish that there was a way to register new patterns globally. I work with MSSQL Server, and have to convert their pattern a lot: 2002-12-12 23:25:29.93. However, I guess we wouldn't want to dump in a million patterns into the core code base. Just thinking outloud... I do think that if someone wants the phaseOfTheMoon code, then it should be in something related to CalendarUtils, not DateUtils at the very least. Maybe o.a.c.lang.time.calendar.PhaseOfMoon Eric Pugh -----Original Message----- From: Henri Yandell [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 17, 2002 10:12 AM To: Jakarta Commons Developers List Subject: Re: [lang] Has anyone thought about a TimeUtils package? On Tue, 17 Dec 2002, Sean Schofield wrote: > > I took a quick look at Joda's date parser and saw it has its own > > engine. > > > > I believe the commons one should lean onto the syntax of the java's, > > such that should allow it as a bug free plug-in replacement of Sun's. > > > > > What do others think? > > I agree. I don't think we want to write a new DateFormat from scratch. > Perhaps we can write our own class with synchronized methods that wraps > the existing SimpleDateFormat (just a thought.) Or maybe we can rip the > source from the JDK version and add the fixes there. Just to get it in quick. -1 to ripping source from the JDK. Licenses bite our arses too quickly when you get near here so it's not something ASF can do. > > I need to take a look at Ant's code. Maybe > > I'll take the leap and start a working bug free plug-in replacement > > of Sun's SimpleDateFormat if no one has taken the lead... > > We have already moved the ant code int the lang module of CVS (moved it > yesterday). Right now its identical to the Ant code. We're going to go > from there. A thread-safe DateFormat would probably be a good next > step. We're also trying to figure out what to do with CalendarUtils > which came from the sandbox. (See the recent email thread concerning > DateUtils for yesterday's discussion on this.) I'm starting to want a time sub-package as this gets larger :) Once it hits 3 classes or so. Hen -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
