"pinkney_b at www.aircom.co.za" <pinkney_b at www.aircom.co.za> wrote:
> What is required, IMHO, is a solution in the spirit of the Integer classes.
> 
>     DateAndTime
>         SimpleDateAndTime
>         PrecisionDateAndTime
>             TimeStamp 

I am sad to see such a useful class getting functionality *removed*.  
Perhaps instead of this, people who want could use "Time secondsClock"?

"Time secondsClock" will give you a raw integer at seconds-level
granularity and it will give you a (non-strictly) monotonically
increasing clock.  That would seem to suffice for uses where you want to
manipulate zillions of times, but where you don't care about high
precision and you don't care about correspondence to time in the outside
world.



> 
> A preference will determine which gets instanciated

Mmmm, this does not seem like a user-level preference, but an app-level
preference.  Even though tinyBenchmarks does not need to use accurate
DateAndTime's, it does need precise ones.  The email reader does not
need precise DateAndTime's, but it needs reasonably accurate ones.  And
apparently (considering the existence of this thread), there are some
lost programs that don't care about precise nor accurate times.  Thus,
surely a user-level preference is not the way to handle this
distinction.  The situation seems to me identical to one like "should I
open the file read-only?".  It would make no sense to have a global
readOnlyFiles preference.


> I have had a draft of this on my pc for a while. I just need to dust it off
> and ensure the two versions play nicely together.


In short, please make sure that all the versions of DateAndTime actually
do make sense as "date and time"'s and that the differences are
transparent to the user.  What you propose is not like the Integer
subclasses, where the differences are completely invisible to the user
except for performance.

To be honest, I am actually quite happy with DateAndTime as it is, and
it is bothersome to hear discussion of *reducing* its functionality.  I
have not yet seen a good case that it is worth sacrificing half of what
little functionality DateAndTime has in order to speed them up.



-Lex


PS -- if you want to speed them up in place, note that the "offset" of a
DateAndTime is usually at *hours* granularity, and thus the nano-second
resolution of Duration is unnecessary.