groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henrik Martin <>
Subject Re: Requesting Advice for Groovy Approach for Unique Date Conversions
Date Tue, 10 May 2016 00:02:41 GMT
What about creating a few utility methods around the standard Java 8 
time/date classes already available in the JDK? I've had to do some date 
conversions myself recently, and found everything I needed in 
java.time.*. It seems to me like your task is mostly a format 
conversion. If so, the various DateFormatter classes are probably 
sufficient. Also, take a look at the jchronic stuff for natural language 
processing of date/time:



On 5/9/16 4:29 PM, Gerald Wiltse wrote:
> Also, something else just occurred to me which might be relevant. 
> Another option might be to create a JDE Calendar or JDE Date class 
> which extends or implements date or calendar classes/interfaces. My 
> first instinct was to convert dates into Date Objects and strings 
> based on Gregorian calendar on their way in and out of the database 
> (because that's what I'm somewhat familiar with).  However, might it 
> be more natural to write classes that let me handle them in their 
> native form without converting?  Maybe thats a more complicated endeavor.
> Gerald R. Wiltse
> <>
> On Mon, May 9, 2016 at 7:04 PM, Gerald Wiltse < 
> <>> wrote:
>     All,
>     In summary, I would like any advice people can offer on how to
>     approach the task below, using the Groovy ways of thinking.
>     The topic at hand is a messy domain-specific problem working with
>     dates in Oracle's ERP software called JD Edwards. It's gory detail
>     is documented here:
>     I wish to write my own solution in Groovy.  A flexible
>     swiss-army-knife type package which lets me pass JDE and Gregorian
>     dates and times (as strings) in and out and define what I get
>     back.  I am not looking for code, but help escaping the procedural
>     mindset. The one senior Java programmer just see's this as a few
>     Static Methods.  I want to know what Groovy developers see.
>     I'm guessing some combination of closures.  Perhaps factory
>     pattern, which I've never used? Does this sound like a "Functional
>     programming" scenario, where functional approach might be a good fit?
>     I want to start off on the best foot possible, but don't have the
>     intuition of high-level groovy thinking yet.
>     Gerald R. Wiltse
> <>

View raw message