Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Re: how do I get ampm format for time?

From: jeff:rebol at: 21-Jan-2001 8:47

Howdy, Bob Racko: Since we're laying into you now: (-: You do make some good points in your message about date type, (grating and apparently at the expense of others, though well meaning, that they appear). :-) Comments below:
> In some cases I made a /local dt and copied your argument > to the local as in > > myampm: func [ adt /local dt ] [ dt: adt/time > ... <your code here> ] > > in order to avoid the intermediate function call overhead. > > Here are test cases derived from actual working sections of > the code where the function is used. > > time-ampm modified? %user.r > > time-ampm ( oo: make object! [ time: now ] )
(Parens are gratuitous above.) Accepting input like the above really complicates your function because you then have two /time refinements to take before you get to your time! value. You have to have stuff like this: if not time? adt [adt: adt/time while [not time? adt][adt: adt/time]] I don't think functions should go rummaging around too far to find the data they're supposed to operate on.
> time-ampm now
But your function does take time! values, yes? time-ampm: func [adt [time! date! object!][ all [not time? adt adt: adt/time] .. can save yourself a gratuitous local. Type specifiers help prevent things like unset! accidently falling into your function as well.
>#2) most of you did not get the fact that the result was to > be fixed width (zero padded on the left) -- the clue was in > the comment ; hh:mm vs [h]h:mm
FORM and MOLD of time values will strip any leading zeros, and I see in your original post that you are interested in a string result. Text formating, to me, is a whole different question. If your time-ampm function renders your time into a string then you loose the semantic use of the original value and can't use the function in composition with others that might continue to operate on 12hour times.
> In the area of potential refinements, I saw very little in > the replies that could be easily tweaked return the two > separate values (AM PM vs 12 hrfmt). I guess it was the > excitement of the hunt.
Again, I didn't know that was desired, but a slight modification my version could have done that easy enough. Ha ha. time-ampm: func [dt [time! date! object!] /dd/ampm/merid][ all [not time? dt dt: dt/time] ampm: pick [PM AM] found? all [24:0 > dt dt >= 12:0 ] if merid [return ampm] reduce [(dd: dt // 12:0) + pick [12:0 0] 1:0 > dd ampm] ] time-ampm/merid now == AM
> so here you also have a lesson in "coupling and cohesion". > RT is to be congratulated in the cohesion of the base > date!time! refinements. I will let you each decide how > badly you sacrificed coupling in the interest of beating a > benchmark.
I would think that rendering your time values to a string would eradicate the possibility of loose coupling.
> Indeed, I was also trying to make the community (not just > RT) aware of practical and potential extensions (see > )
Yes-- contributions so far have been very minimal.
> or > alternatively, refinements to the base time!date! types > involved. (see refinements below) > > Being the stickler for orthogonality I am, I noted that > REBOL can accept 12hour format but is not so good at > emitting it (or allowing the programmer to). > > print 20-Jan-2001/08:57PM > > By pointing out so many different ways one can make > mistakes at the boundaries in emitting it and getting you > to come up with a concise function that does it all, I make > it attractive to be standardized or codified. > > If any of you want to resubmit a better and more concise > solution (read succinct) that RT can consider for a to-ampm > (like to-idate) with refinements that allow selective > inclusion/exclusion of the parts then lets hear it!
TO-IDATE is a fudge function there to meet a specific practical need within the protocol handlers-- (likewise CVS-DATE function). I suppose an ampm function would be for useful for similar fudge. So I suppose string output is what you'd have to get.
> In the meantime, what if it were just a simple part of the > datatypes involved? > > As I have watched Rebol evolve, "being able to get [at] > only what you are interested in" > is a characteristic of the base type support in the > language. > > --proposed refinements--
> /inampm -- time > > portion as [h]h:mm:ss[A|P]M, > variable width hh, first hour is 12 not 0 > can be combined with /time to return time > only portion > > Time Refinements: > /hour -- (stet) /minute -- (stet) /second -- (stet) > /ampm -- ante meridiem, returns "AM" or "PM" /in12hr > -- [h]h:mm:ss, variable width hh, first hour is 12 not > 0
I don't know-- do the /ampm refinements permanently side effect the datatype? The issue is one of FORM and MOLD of a date! or time! value, not a question of accessing inner data in the value as the rest of the date/time refinements do. date: now ampm-date: date/ampm ? Doesn't really make sense. The other way to go is a system setting that affects how things like date! and time! values are printed. You see this, for instance, with system/options/binary-base . The larger question of text formating is one we have talked about addressing with a format dialect. Using parse block, it's pretty easy to make little formatting dialects to experiment with. Someone might make a dialect that just handles the many numerous ways to FORM, MOLD and print dates and times. Cheers! -jeff