On Tue, 17 Dec 2002 [EMAIL PROTECTED] wrote:
> 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. Stack overflow worry. Let's also remember that we want to avoid grandoise thoughts of huge libraries :) > 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... Yeah. Might just be an implementation of Pool, the DateFormat pool example or something. > 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 Kick it out :) Which raises some questions. If Ant does need it, then they'll still be maintaining their own. Also, if Ant drop their code, then the highly useful [to coven's of witches] phase of moon code will vanish from sight. Hen -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
