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
> http://rebol.com/contribution_source.html )
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
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
