#241 Add classes to for easy date/time manipulation.

v3.2.0
closed
Rick McGuire
Classes (154)
5
2012-08-14
2007-09-26
Rick McGuire
No

It's time to get the venerable date() and time() builtin functions an upgrade. There are a lot of operations (such as date comparison, date math, etc.) that will be easier to deal with using an oo approach.

Discussion

  • Mark Miesfeld
    Mark Miesfeld
    2007-09-26

    Logged In: YES
    user_id=191588
    Originator: NO

    Rick, I like this idea a lot. (Especially since you are doing the work. <grin> I was impressed by your recent work for the 'F' option on date and time.)

     
  • Rick McGuire
    Rick McGuire
    2007-09-27

    Logged In: YES
    user_id=1125291
    Originator: YES

    I've checked out the prototype into the incubator already. This HEAVILY leverages the date('F')/time('F') code. I'd appreciate any/all feedback on this. I'd actually like to include this in 3.2.0 if I'm comfortable that it's fully baked or not. There are a couple specific points I'd like some feedback on.

    1) The TimeSpan class has a number of total* methods (totalHours, totalMinutes, etc.) that return fractional results ( e.g., 1.5 hours). The calculation is done using numeric digits 18 because I'm working with very big numbers. This can result in numbers with lots of decimal places. Should I cap the resolution of the return result? If so, how many decimal places should I truncate to?

    2) The classes have a number of class methods that are "fromXXXXXX" to translate from various string formats into an instance of the object. The TimeSpan class has a string format that's roughly -dddddddd.hh:mm:.ss.uuuuuu ", with the sign and days being optional. What name should I apply to this for my "fromXXXXX" method? Right now, all I have is "fromString", since that's what the string method returns.

    3) In the DateTime class, I have class methods such as "fromEuropeanDate" that do the same as above. These feel a little wordy (mostly because I have "Date" on the end of the method name). I ended up doing this because this class merges functions of both date() and time(), and both functions have a "Normal" format. This caused me to create "fromNormalDate" and "fromNormalTime" and add a "Date" or "Time" qualifier to most of the other formats. Should I drop the "Date" from the methods or keep them for consistency?

    4) Should these be in the core set of classes (no requires needed), or a separate .cls file.

     
  • Rick McGuire
    Rick McGuire
    2007-09-27

    Logged In: YES
    user_id=1125291
    Originator: YES

    A "kick-the-tires" version has been checked into the 3.2.0 tree.

    Committed revision 824.

     
  • Mark Miesfeld
    Mark Miesfeld
    2007-09-27

    Logged In: YES
    user_id=191588
    Originator: NO

    I've checked out the prototype into the incubator already. This HEAVILY
    leverages the date('F')/time('F') code. I'd appreciate any/all feedback on
    this. I'd actually like to include this in 3.2.0 if I'm comfortable that
    it's fully baked or not. There are a couple specific points I'd like some
    feedback on.

    I'd like to see this get into 3.2.0 also. Maybe we can get Lee (hint, hint <grin>) to help check it out.

    4) Should these be in the core set of classes (no requires needed), or a
    separate .cls file.

    My first take on this is they should be in the core classes. I think of Time and Date as being part of the fundamental Rexx functions. And I see this as part of the natural evolution of the fundamental Rexx functions to objects.

    As to the other points, I need to see if I can get some time to play around with the classes somewhat. Although, my feeling is that on this:

    'I have class methods such as "fromEuropeanDate" that do the same as above. These feel a little wordy'

    you are probably right that it is more wordy than neccessary. But, maybe I should use the classes in some code before I make up my mind.

     


Anonymous


Cancel   Add attachments