TimeStamp, Date and Time Thoughts...

The way Date, Time and TimeStamp are created seems a little inconsistent.
For example:

Date new. "The current Date."
Time new. "The current Time."
TimeStamp new. "Returns a TimeStamp with a nil date and time. This seems
like it should be set to the current date and time for consistency. "

TimeStamp current. "The current date and time"
Time current. "Not supported."
Date current. "Not supported."

I think there might be value in more consistent behavior over all three of
these classes.  The Time class<<now method might also be a candidate for
implementation in the other classes, but I am not as concerned since I don't
use it. ;)  When I am working with times and dates I need to stop and think
about whether I should use new or current.

Also it seems that the default Dolphin Date string representation is a bit
on the verbose side (ex: 'Wednesday, June 27, 2001').  Sometimes I
appreciate the value of the long Date string, but often it is more than I
want.  I implemented a shortDateString method:

Date<<shortDateString

    "CJD 11-28-2000 Return a short date string."
    | strm |

    strm := String new writeStream.
    self printOn: strm format: 'M/dd/yyyy'. "I suppose I should use: Date
defaultShortFormat"
    ^strm contents

But I am curious about what others do regarding this, or does everyone like
long date strings? ;)  I know I can change the default date format, but I
would rather just get a long or short date string on demand.  I don't
generally like adding many loose methods to system classes.  Would there be
value in adding some messages to get either a long or short date string to
the base system?

Just some ideas...

Chris

"Christopher J. Demers" <[hidden email]> wrote in
message news:9hdtil$df4vp$[hidden email]...
I suppose, the code should be:

asShortDateString
 ^ Locale default printDate: self format: nil flags: DATE_SHORTDATE

You are living in multilanguage world, I guess :))

Christopher

You wrote in message news:9hdtil$df4vp$[hidden email]... don't
> use it. ;)  When I am working with times and dates I need to stop and
think
> about whether I should use new or current.

I agree that TimeStamp class>>new should work consistently with Time and
Date's implementations (defect 288).

Time class>>now and Date class>>today are original Smalltalk-80 messages.


> Also it seems that the default Dolphin Date string representation is a bit
> on the verbose side (ex: 'Wednesday, June 27, 2001').  Sometimes I
> appreciate the value of the long Date string, but often it is more than I
> want....

Well that is the default long date format if you are using a US locale. We
omit the day name (and of course write the date number first) in the UK.
Editing the regional settings can shorten it to the more sensible (:-)) UK
style, or use the (rather confusingly named) Date class>>defaultLongPicture:
method as follows:

Date defaultLongPicture: false
Hey presto, Dates will now print using a short picture by default.

Otherwise #printOn:longPicture: (which shouldn't be Private) will give a
short or long format, depending on whether one passes true or false as the
second argument. The result will be formatted according to the default
formats for the locale of the host OS. If you want a convenience method to
return a string, then a loose method will have to be added at the moment.

Regards

Blair

Chris,

> The way Date, Time and TimeStamp are created seems a little inconsistent.

Agreed. One reason is that the days of the Date/Time/TimeStamp classes
appeared to be numbered with the advent of the ANSI standard and it's
DateAndTime/Duration classes. I guess the older classes were then seen as
legacy and haven't been "honed" as much as other classes in the image.

DateAndTime/Duration haven't actually been implemented yet - as you can see
from the stubs in the current image. I've had a couple of looks at it over
the years but it is actually a bit more complicated to implement (in what I
would consider an acceptable way!) than it first looks and I never really
got anywhere.  I don't know how high OA have it in their #toDo list, or
whether anybody else is having a go at it? If not then I might have another
try. I did wonder about suggesting it as a sort of group project, using
SourceForge or something similar, but I don't really know if that is such a
good idea.  Comments?

> Also it seems that the default Dolphin Date string representation is a bit
> on the verbose side (ex: 'Wednesday, June 27, 2001').  Sometimes I
> appreciate the value of the long Date string, but often it is more than I
> want.  I implemented a shortDateString method:
[]
> But I am curious about what others do regarding this, or does everyone
> like long date strings? ;)  I know I can change the default date format,
> but I would rather just get a long or short date string on demand.  I
> don't generally like adding many loose methods to system classes.
> Would there be value in adding some messages to get either a long
> or short date string to the base system?

FWIW I usually just use the converter classs, DateToText and TimeToText,
either creating one instance owned by the class that wishes to do a
conversion or just creating an instance on the fly for the occasional
occurrence. It's a bit more long winded (and less OO!) but quite flexible
for the Date->Text direction. I've found that the Text->Date direction is a
bit more problematic and can get a bit confused in certain locales so I tend
to avoid that.

Regards
    Ian

On Thu, 28 Jun 2001 15:18:32 +0100, "Ian Bartholomew"
<[hidden email]> wrote:

I did a clumsy implementation for Dolphin 3.0 (and Squeak) posted it
on my web page about a year ago.  Hey, it passes the SUnit test -- but
I wrote the tests.  Isn't that sort of like playing guess the number
with yourself?

The version on my web page uses the Date and the Time classes
internally.  I recently reworked it for Dolphin 4.0 to use
microseconds from an epoch (1970?) instead.  I also use the underlying
OS services to handle Daylight Savings and a few other
internationalization stuff -- pulled some major ugly experiments out
of it that way.

I also reworked my ANSI ScaledDecimal to use integers internally with
a scale factor to get around some representation anomalies I saw.

It is usable for my purposes but I haven't finished it.  There didn't
seem to be that much interest in ANSI DateAndTime, Duration, and
ScaledDecimal and I wanted to get on with my Genealogy program.

I think that the most of the work of ANSI DateAndTime protocol could
be handled by the underlying OS services or CLIB.dll (C ANSI Time
functions).  I had some Windows SDK problems and some questions about
the proposed new C time functions.

> I've had a couple of looks at it over
>the years but it is actually a bit more complicated to implement (in what I
>would consider an acceptable way!) than it first looks and I never really
>got anywhere.  I don't know how high OA have it in their #toDo list, or
>whether anybody else is having a go at it? If not then I might have another
>try. I did wonder about suggesting it as a sort of group project, using
>SourceForge or something similar, but I don't really know if that is such a
>good idea.  Comments?
[snip]


I think a portable ANSI DateAndTime and Duration implementation could
be done C time functions.  This might make a nice project, but I'm not
sure there is much interest in it.  SourceForge is a good place for
this.  I'd like to see a portable ScaledDecimal implementation project
also.

I'll gladly send my reworked ANSI DateAndTime, Duration, and
ScaledDecimal to anyone that wants it, or post it if there is
interest.  I also have SUnit tests for them.


--
Richard A. Harmon          "The only good zombie is a dead zombie"
[hidden email]           E. G. McCarthy

Hello Ian, hello Richard,

Brent Pinkney has also written ANSI standard DateAndTime and Duration
for Squeak 3.1 http://minnow.cc.gatech.edu/squeak/1871.
I think the implementation will be simpler by using a real number with
sufficient
precision in place of  'jdn seconds nanos' but this is a small details...

In my spare time I try to develop some helping tools with Dolphin
for astronomy purpose and I use julian day to do calculations
based on a book by Jean Meus.

Julian Day is a linear count of days starting on January 1, 4713 BC and is
commonly
used for astronomical calculations. The Julian Day starts at Noon Universal
Time (UT)
hence at 0h UT the Julian day is some whole number + 0.5.

There exist standard conversion algorithms between julian day number and
Gregorian date (our claendar).

I was a little disapointed when I found that the classes DateAndTime and
Duration
with a notYetImplemented in all methods. If there is some interest we could
write these classes but they must be open source and included in a future
patch
of Dolphin as soon as they seem stable.

Have a nice day
Alain



"Richard A. Harmon" <[hidden email]> a écrit dans le message news:
[hidden email]...
> On Thu, 28 Jun 2001 15:18:32 +0100, "Ian Bartholomew"
> <[hidden email]> wrote:
>
> >Chris,
> >
> >> The way Date, Time and TimeStamp are created seems a little
inconsistent.
> >
> >Agreed. One reason is that the days of the Date/Time/TimeStamp classes
> >appeared to be numbered with the advent of the ANSI standard and it's
> >DateAndTime/Duration classes. I guess the older classes were then seen as
> >legacy and haven't been "honed" as much as other classes in the image.
> >
> >DateAndTime/Duration haven't actually been implemented yet - as you can
see I
> >would consider an acceptable way!) than it first looks and I never really
> >got anywhere.  I don't know how high OA have it in their #toDo list, or
> >whether anybody else is having a go at it? If not then I might have
another
> >try. I did wonder about suggesting it as a sort of group project, using
> >SourceForge or something similar, but I don't really know if that is such
a

On Fri, 29 Jun 2001 14:10:13 +0200, "Alain Fischer"
<[hidden email]> wrote:

>Hello Ian, hello Richard,
>
>Brent Pinkney has also written ANSI standard DateAndTime and Duration
>for Squeak 3.1 http://minnow.cc.gatech.edu/squeak/1871.

Thanks.  I'll have look and run it through my version of the
CampSmalltalk SUnit ANSI tests.  That is if I can easily get Brent
Pinkney's DateAndTime and Duration into Squeak 2.7 which is the last
version I worked with before moving on to Dolphin.


>I think the implementation will be simpler by using a real number with
>sufficient
>precision in place of  'jdn seconds nanos' but this is a small details...

Yes.  I used a real number (Float) in the reworked version, but I
wasn't sure what the appropriate precision should be so I just copied
the Date class precision.


I'm not sure it matters what epoch one uses as I think any two epochs
can be related easily to each other.

I would think there is a C library that has implemented this, and a
portable implementation might be based on calling this.  The library
may well be implemented in terms of the ANSI C date?/time function,
and these can and probably need be used.


>I was a little disapointed when I found that the classes DateAndTime and
>Duration
>with a notYetImplemented in all methods. If there is some interest we could
>write these classes but they must be open source and included in a future
>patch
>of Dolphin as soon as they seem stable.
[snip]

I'd like to see them in a Dolphin release also.

All of my ANSI stuff has been open sourced, and available for some
time.  I'd like to try to contribute to any effort to make the ANSI
DateAndTime, Duration, and ScaledDecimal protocols available in all
Smalltalk dialects.

It's self interest on my part as my Genealogy program uses a lot of
dates and I'd like it to be portable across Smalltalk dialects.


--
Richard A. Harmon          "The only good zombie is a dead zombie"
[hidden email]           E. G. McCarthy

Richard/Alain,

> >I think the implementation will be simpler by using a real number with
> >sufficient
> >precision in place of  'jdn seconds nanos' but this is a small details...
>
> Yes.  I used a real number (Float) in the reworked version, but I
> wasn't sure what the appropriate precision should be so I just copied
> the Date class precision.

I've had a go at implementing Duration and ended up using Fraction for
storing the internal state. I thought about Float but that seemed a bit
dangerous because of the loss of precision when manipulating Durations and
the problems associated with testing Floats. Using Integers solved those
problems but then makes you define a precision level, something that
Duration probably shouldn't have - someone somewhere will want to use it for
picoSeconds or whatever. I settled on Fraction as it seems to solve _most of
the difficulties (see the previous thread <g>)

I'm not so sure about using Floats for DateAndTime? I intended to use
Integer and define a maximum precision (milliseconds) - it seems safer
somehow. Adding two DateAndTimes together, or a DateAndTime and a Duration,
and then comparing with another DateAndTime would seem a common use. I would
have thought that using Float would run the risk of the comparison failing
because of Float imprecision?

Ian

Ian, Richard,

I'd worry about any implementation of DateAndTime and Duration which didn't
store times to the same resolution.  Given:

    aDate := ...
    aDuration := ...
    anotherDate := aDate + aDuration.

I'd want it always to be true that:

    (anotherDate - aDate) = aDuration.

Also, I'm inclined to agree with Ian's point about using fractions to allow
arbitrary precision -- after all, there is no reason why D&T and Duration
might not be used to represent times measured on a different machine with a
*much* greater precision than a PC clock.

OTOH, I'd be quite happy with an implementation which just worked to some
(high) fixed level of precision, especially if it were factored in such a
way that I could easily change the precision and/or representation.

    -- chris

In previous years, I've used seconds with an arbitrary setpoint of
0000 GMT 1 Jan 1950.  Integers could be positive or negative with
respect to that point.  Of course, I was dealing with a fairly coarse
resolution.

Larry
--
[hidden email]

"Chris Uppal" <[hidden email]> wrote (with
possible editing):

Chris,

> Also, I'm inclined to agree with Ian's point about using fractions to
> allow arbitrary precision -- after all, there is no reason why D&T and
> Duration might not be used to represent times measured on a different
> machine with a *much* greater precision than a PC clock.

Good point. I wasn't so sure about the need for D&T to be as accurate as
Duration but this, and your comment about adding/subtracting Duration's from
DateAndTime show that Fraction is probably a good idea for both.

> OTOH, I'd be quite happy with an implementation which just worked to some
> (high) fixed level of precision, especially if it were factored in such a
> way that I could easily change the precision and/or representation.

My version of Duration works with Fractions as it's internal representation
and is therefore always accurate. Constructor arguments can be any <number>
but are converted on instance creation. However, following on from the other
thread, I've restricted the conversion of Floats to 6 decimal places which
solves the #asTrueFraction / #asApproximateFraction dilemma (I've added
#asRoundedFraction to Float and Number).  I don't think this rounding is a
problem in practice as, if needed, you can specify more precision by using
ScaledDecimals for the argument.

Ian

BTW, Does anyone else find DateAndTime an "unsatisfactory" name for the
class?. I'm not saying I could do any better, but it just doesn't seem to
scan correctly.

> BTW, Does anyone else find DateAndTime an "unsatisfactory" name for the
> class?. I'm not saying I could do any better, but it just doesn't seem to
> scan correctly.

I wrote a class once (as part of a time library) to represent moments, and I
called it Moment. Worked for me.

Regards,

Peter van Rooijen

P.S. The gobo Eiffel project has a very well thought through time library.
Very good inspiration for someone who wants to implement a really useful
time library for Smalltalk.

http://www.gobosoft.com/eiffel/gobo/time/

Peter,

> I wrote a class once (as part of a time library) to represent moments, and
I
> called it Moment. Worked for me.

Some statisticians might disagree with you though.  Come to think of it, the
mechanical engineer in me is a little bothered by it too :)

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Hi Bill,

I think I understand the engineer part, but the statistician? In any case,
if your objection had a serious element to it, I'd say that every class
(name) is used in a context, never a vacuum, and 'moment' doesn't confuse in
any way, and is very easy to use.

Say you make a Period object (I would _not_ call it a TimePeriod because
it's redundant - again because of context), then it's easy to give it a
firstMoment and a lastMoment, and you know exactly what you are talking
about.

firstDateAndTime and lastDateAndTime just doesn't work, does it?

Best,

Peter

"Bill Schwab" <[hidden email]> wrote in message
news:9hmfgt$rkj$[hidden email]...
> Peter,
>
> > I wrote a class once (as part of a time library) to represent moments,
and
> I
> > called it Moment. Worked for me.
>
> Some statisticians might disagree with you though.  Come to think of it,
the

Peter van Rooijen wrote:
> I think I understand the engineer part, but the statistician?

I forget the exact definition of the statistical moments, but each nth
moment is some combination of the data values rased to the nth power.  The
0th moment is the number of data items; the first is the mean; the second is
closely related to the variance, I think the third is a measure of the
skewedness of the distribution, and so on.

> In any case,
> if your objection had a serious element to it, I'd say that every class
> (name) is used in a context, never a vacuum, and 'moment' doesn't confuse
in
> any way, and is very easy to use.

I don't know how serious Bill was being either (though I suspect he was only
teasing ;-), but I am serious.  Class names share the a global namespace, so
it's a requirement that they be given clear and globally unambigious names
(as far as possible and within reason).  I don't mean the practise of
prepending a 3 letter identifier to the class name (though that does help
avoid name clashes), but that the meaning of a class should be evident from
its name.

In my current image there are three classes with names:
DhbStatisticalMoments, DhbFastStatisticalMoments, and
DhbFixedStatisticalMoments; so this is not just an academic point.

> Say you make a Period object (I would _not_ call it a TimePeriod because
> it's redundant - again because of context)

Sure, but that's the context of the name used to refer to the object, not
the context of the class name.

> Peter

Ian,

> BTW, Does anyone else find DateAndTime an "unsatisfactory" name for the
> class?. I'm not saying I could do any better, but it just doesn't seem to
> scan correctly.

No, I don't like it either.  Even just DateTime rings better.

Personally I'd have preferred just "Time", but presumably the pre-existing
ST-80 Time class was too far distant from what the ANSI folk wanted from
DateAndTime.

Also, I was surprised in a discussion on c.l.s some time ago at how many
people seem to interpret Date as just meaning a specific day, and Time as
just meaning a time *within* a day.  Possibly this is a subtle difference
between British and US usage.

    -- chris

On Fri, 29 Jun 2001 23:48:29 +0100, "Ian Bartholomew"
<[hidden email]> wrote:

I noticed I wasn't very clear about the internals of my reworked
DateAndTime, Duration, and ScaledDecimal in previous posts.

DateAndTime instance variables:
        utcMilliseconds <integer>       date and time minus epoch
                                        (1901) in microseconds.
        localOffset     <Duration>      utcMilliseconds + offset ->
                                        UTC (- west / 0 UTC / + east).

Duration instance variables:
        asSeconds       <number>        seconds long.

ScaledDecimal instance variables:
        unscaledValue   <integer>       unscaled digits.
        scale           <integer>       digits to right
                                                                of decimal point.


>I'm not so sure about using Floats for DateAndTime? I intended to use
>Integer and define a maximum precision (milliseconds) - it seems safer
>somehow. Adding two DateAndTimes together, or a DateAndTime and a Duration,
>and then comparing with another DateAndTime would seem a common use. I would
>have thought that using Float would run the risk of the comparison failing
>because of Float imprecision?

I saw representation errors when using <Fraction> in ScaledDecimal.
That these errors could crop up in Duration asSeconds never occurred
to me.  Thanks Ian.  I'll have to go back and fix this in my reworked
version to use <rational> (<Fraction> or <integer>) for Duration
asSeconds instead of <number>.


In a post on c.l.s about ScaledDecimal representation errors using
<Fraction> David Simmons suggested using <integer> for unscaledValue
and scale.  This is the approach I used in my reworked version of
ScaledDecimal.  He also described in detail some ScaledDecimal speed
optimizations to use registers that I haven't explored yet.  A very
informative post.


I invariably find his posts informative and worth reading even when
the subject is way over my head.  He also posted to c.l.s about the
ANSI DateAndTime which was particularly helpful to me on Wed, 28 Mar
2001.  I think it is worth looking at as he covers many important
issues on <DateAndTime>.


An associated set of SUnit Tests for the ANSI Date and Time protocols
with an implementation would be useful.  I'd prefer if they used the
CampSmalltalk SUnit Testing Framework.


I though using the ANSI C (or POSIX?) standard might leverage off a
great deal of work done by others if it could accommodate the ANSI
Smalltalk requirements.  I thought it would likely be robust and
reliable, also.  I'm not sure which would be most useful.  I planned
to check out how Lisp implementations handle date and time when I get
back to my implementation.


The logical Genealogy data model I am using in my Genealogy program
seems to indicate fields specified as date type were capable of
holding what seemed to be a database date (and time I think) or date
and time span (ie 2001-12-20 through 2001-12-25 and maybe time).  I
also noticed on a web page about the Proposed 2000 ANSI C time
functions a mention of POSIX time spec. that said something like a
string that starts with anything other than ":" was to create a date
(and time?) and one starting with ":" was to create a date (and time?)
span.

I didn't see anything on record fields in Microsoft Access that looked
like it would hold anything other than just a single date.  Is a date
and time database record field type common on industrial strength DBs
and just not in MS Access?  Is date (and time?) span field type
common?  Can anyone shed some light on this?


--
Richard A. Harmon          "The only good zombie is a dead zombie"
[hidden email]           E. G. McCarthy

On Sat, 30 Jun 2001 12:53:13 +0100, "Chris Uppal"
<[hidden email]> wrote:

>Ian, Richard,
>
>I'd worry about any implementation of DateAndTime and Duration which didn't
>store times to the same resolution.

That's a good point.  I just convert the Duration asSeconds to
milliseconds (microseconds?) before arithmetic.  I thought I try to
get it to do it right, then try to make it fast later.


>  Given:
>
>    aDate := ...
>    aDuration := ...
>    anotherDate := aDate + aDuration.
>
>I'd want it always to be true that:
>
>    (anotherDate - aDate) = aDuration.

I'll have to check my tests, but my implementation should do this.
Thanks.


>Also, I'm inclined to agree with Ian's point about using fractions to allow
>arbitrary precision -- after all, there is no reason why D&T and Duration
>might not be used to represent times measured on a different machine with a
>*much* greater precision than a PC clock.

Really excellent point.  I noticed this seemed an important point
mentioned in material I found on the web that talked about dates and
times.


>OTOH, I'd be quite happy with an implementation which just worked to some
>(high) fixed level of precision, especially if it were factored in such a
>way that I could easily change the precision and/or representation.


That is one reason I didn't worry too much about what precision to
use.  I have enough problems figuring out what it the behavior of the
Date and Time protocols is.  I figured if I got it doing the right
thing. I could extend the precision pretty easily later.


One thing that has really been driving me nuts is what DateAndTime
class >> #clockPrecision does and how to implement it.  The
description is:

Answer a <Duration> such that after that period of time passes, #now
is guaranteed to answer a different <DateAndTime>.  Ideally this
should be the minimum such duration.

I posted to c.l.s asking about "ANSI - (<DateAndTime factory>,
clockPrecision)?" on 22 Nov 2000.  A number of kind folks responded
and I tried out what they suggested but I couldn't come up with
anything that seemed reasonable to me.  For instance the following is
an excerpt from a response:

========
Provided that the resolution is significantly coarser than the time
required to fetch the clock value one simple way is to get an initial
value and then loop getting subsequent values until the returned value
changes.  The difference between the two values *should be* the clock
resolution. For example

    clockResolution
        | initialMilliseconds subsequentMilliseconds |
        initialMilliseconds := Time millisecondClockValue.
        [subsequentMilliseconds := Time millisecondClockValue.
         subsequentMilliseconds = initialMilliseconds] whileTrue.
        ^subsequentMilliseconds - initialMilliseconds

This version doesn't take into account clock roll-over, but VW's
millisecond clock handles rollover for you.
========

It seems to answer how long it took to do the above block.  That
doesn't seem like what the ANSI standard spec. seems to me to specify.
The hard part seems to be the "guaranteed" part.  I don't know that
anything can be guaranteed to happen in Smalltalk.

What is its intended use?  I just don't seem to fathom what this
animal is.  I noticed the ANSI C time functions (or a struct)
specified a field with the clock speed.  That seemed more like what
the ANSI standard spec. seems to me to specify.

I think I'm just badly confused.  Not unusual.

I'll sort this out when I get back to fiddling with my Date and Time
protocol implementation.


--
Richard A. Harmon          "The only good zombie is a dead zombie"
[hidden email]           E. G. McCarthy

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
> Ian,
>
> > BTW, Does anyone else find DateAndTime an "unsatisfactory" name for the
> > class?. I'm not saying I could do any better, but it just doesn't seem
to
> > scan correctly.
>
> No, I don't like it either.  Even just DateTime rings better.
>
> Personally I'd have preferred just "Time", but presumably the pre-existing
> ST-80 Time class was too far distant from what the ANSI folk wanted from
> DateAndTime.

I actually pushed for this very argument position while participating in the
ANSI process.

<g> QKS Smalltalk has always had just a <Time> class, and a variety of
<ClockDevice> classes.

QKS-Smalltalk/SmallScript provides shared-variable aliases for <DateAndTime>
that map to the <Time> class. There is also a whole set of issues I'll
mention only in passing regarding notions of "units" of measure. I.e., units
of (measure of) time vs absolute/fixed time from some particular human
historical event.

>
> Also, I was surprised in a discussion on c.l.s some time ago at how many
> people seem to interpret Date as just meaning a specific day, and Time as
> just meaning a time *within* a day.  Possibly this is a subtle difference
> between British and US usage.

That's an interesting point of view (as usual) that I had not considered?

--
-- Dave S. [ http://www.smallscript.net ]

>
>     -- chris
>
>

Richard,

> One thing that has really been driving me nuts is what DateAndTime
> class >> #clockPrecision does and how to implement it.

I've been avoiding this one <g>. One thing I did have in mind was a test
that Dolphin does on startup (I can't remember where but it caused me a
problem once when I upgraded to a new machine) that does a quick test for
machine speed. It _may_ be of use.

Ian