groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henrik Martin <hen...@netgate.net>
Subject Re: Requesting Advice for Groovy Approach for Unique Date Conversions
Date Tue, 10 May 2016 02:42:14 GMT
Always happy to help open up cans of worms :-)
I ended up with a simplistic utility class with a private no-arg 
constructor and a few static methods for the particular conversions I 
needed to do. Not sure if there's a "Groovy best practices" approach to 
this, but I didn't need anything more sophisticated in my case. Please 
share what you end up doing. Cheers,

-H

On 5/9/16 5:20 PM, Gerald Wiltse wrote:
> Thanks for the feedback Henrik!  You've led me to a new can of worms, 
> to see if Oracle and the JodaTime guys made any accomodations for 
> handling JD Edwards time formats in JSR 310. Probably not, but now i 
> have to find out.
>
> The core strategy I'm asking about is how to approach the inevitable 
> custom broker/wrapper classes or methods which always need to exist in 
> the middle.  Classes or methods which take the data as it comes into 
> the app, and prepare it for the API's of libraries, and then do 
> something useful with the output.
>
> Regards,
> Jerry
>
> Gerald R. Wiltse
> jerrywiltse@gmail.com <mailto:jerrywiltse@gmail.com>
>
>
> On Mon, May 9, 2016 at 8:02 PM, Henrik Martin <henrik@netgate.net 
> <mailto:henrik@netgate.net>> wrote:
>
>     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:
>
>     https://github.com/samtingleff/jchronic
>     http://mvnrepository.com/artifact/com.rubiconproject.oss/jchronic
>
>     Cheers,
>
>     -H
>
>
>     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
>>     jerrywiltse@gmail.com <mailto:jerrywiltse@gmail.com>
>>
>>
>>     On Mon, May 9, 2016 at 7:04 PM, Gerald Wiltse
>>     <jerrywiltse@gmail.com <mailto:jerrywiltse@gmail.com>> 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:
>>
>>             http://stackoverflow.com/questions/1171208/what-is-the-precise-definition-of-jdes-julian-date-format
>>
>>
>>         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
>>         jerrywiltse@gmail.com <mailto:jerrywiltse@gmail.com>
>>
>>
>
>


Mime
View raw message