TimeStamp, Date and Time Thoughts...

Richard,

I've got both DateAndTime and Duration working with Fractions now. This
means I've got no restrictions on the magnitude of  DateAndTime and no limit
on the precision of Duration whilst retaining the ability to do all
calculations and comparisons exactly [1]. It's all (with the exception of
Locale stuff (day names) and OS calls to get the current time and Timezone
information) written in Smalltalk which, as far as I'm concerned is a plus
<g>

It's not finished yet, and I'll be trying to blag a copy of your test suite
in the near future (please?), but it's more enjoyable than I thought it was
going to be!

> 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.

Agreed. I did intend to write tests as I went along but, ummm, well you know
<g>

Ian

[1] With the exception of the input/output code where I have to do a
Fraction/Float conversion.

Richard,

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

I think it's intended to tell you the resolution of the clock that's being
used to implement <DateAndTime factory>#now.  This is one of those cases
where the selector itself is clearer than the "explanatory" text.

I don't think it's often very useful (I suspect that the main reason for its
inclusion is a holdover from systems -- common in the UNIX world -- where
the system clock reports time in "ticks" rather than msecs (or whatever),
and so you *need* to know how long a tick is).  However it can be useful
occasionally.  The only case I've been able to come up with so far is:

Suppose you are collecting data about the time it takes for some quick
process to complete.  You are going to do statistical analysis on that data.
Lets say you are measuring the reaction times of a cockroach to various
stimuli. Looking at the data, you notice that all the reaction times for
touching its legs are the same at 10 msec, and that all the reaction times
for touching its antennae are the same at 20msec.  Does that mean that
cockroaches have identical reaction times on all their legs ?  Does it mean
that it takes the horrible little beasts twice as long to react to their
antennae as their legs ?  You don't know unless you know the timing
resolution.  If the clock has a resolution of 10msec, then the above data
would be almost meaningless since all you would have been doing was
measuring the clock.  OTOH if the clock resolution was 1msec or better, then
you'd have interesting data suggesting that cockroaches are wired very oddly
inside.

As far as implementing it goes, the only ways of providing the guarantee
that the standard mentions requires that you have access to the underlying
implementation of the #now method. *If* the lower-level (OS or hardware)
facility it uses provides the data (with a guarantee) that #clockPrecision
requires then you can use that.  I suspect that few systems do provide such
guarantees, unless you have control over the hardware itself.  E.g. I don't
think it's possible to do it using portable C, so I don't think its possible
to write a fully conforming ST implementation in portable C.  Of course, I'm
assuming that the option of just returning some Very Large <Duration>
(10^100 years, say) is unacceptable.

So, a fully portable implementation is impossible.  I think you have only
the options:

Give up, and just return -- say -- 1 second.  This conforms to the standard,
but isn't actually any use to anyone.

Use a loop like the one that Elliot posted to c.l.s to *measure* the
resolution of the clock.  This is portable but you loose the guarantee.  BTW
I'd go around the loop more than once for extra reliability.  Since the
"guarantee" required by the standard isn't actually achievable or relevant
in practice (since the intent of the method is to provide info about the
resolution of the clock, not to provide guarantees about the way it ticks),
I'd not worry about that.  This is probably the best you can do portably.

Use your knowledge of the underlying implementation to "cheat".  E.g. if you
are doing this on Dolphin, and using the Delay class>>millisecondClockValue
to help create your <DateAndTime> and <Duration> objects, then you might
"know" that #millisecondClockValue has a resolution of 1 msec.  This works
but is non-portable.

BTW.  I think there's something slightly screwy about the way that ANSI put
#now on <DateAndTime factory>.  I'd say that there should at least be
another #now on <Duration factory> (answering the <Duration> since some
arbitrary, system defined, event), since:

a) It is usually possible to provide this to greater precision than you can
the absolute time (E.g. on UNIX you can ask the system for *either* the
number of ticks since system startup, *or* the date/time accurate (if you're
lucky!) to 1 second.

b) Duration-since-arbitrary-event avoids all the mucking about with
timezones, etc, which are built into <DateAndTime>, which can be slow, and
may well be misleading.  E.g. if you happened to sample the above cockroach
at *just* the wrong moment in the shift between daylight saving and normal
time, and you were using <DateAndTime>#now, then its reaction time (as I
read the ANSI stuff) should turn out to be a Duration of 1hour 0.01secs (you
can avoid that affect -- I *think* -- by converting both instances of
<DateAndTime> to UTC before subtracting).

The end result is that on OSs which report can report durations to greater
precision than they can date/times (e.g. Windows, UNIX), it is difficult or
impossible for a Smalltalk implementor to provide ANSI-compliant access to
the higher resolution of the millisecond clock (or whatever).

As an example, inspect:

    a := Array new: 2000.
    1 to: a size do: [:i | a at: i put: Time now].
    (a collect: [:each | each asMilliseconds]) asSet asSortedCollection
asArray.

You'll see that Time now (which seems to access my Windows 98 system clock)
has a resolution of between 50 and 60 msecs (on this machine all the msec
values are either 50 or 60 msecs apart).  Using Elliot's loop (with a few
refinements) for the same measurment:

    start := Time now.
    [(now := Time now) = start] whileTrue.
    begin := start := now.
    ticks := 0.
    [ticks < 100] whileTrue:
         [[(now := Time now) = start] whileTrue.
         start := now.
         ticks := ticks + 1].
    end := now.
    (end asMilliseconds - begin asMilliseconds / ticks) asFloat.

gives values which vary a little around 55.0

OTOH, using a similar loop to measure the resolution we could use for
<Durations> using the Delay class:

    start := Delay millisecondClockValue.
    [(now := Delay millisecondClockValue) = start] whileTrue.
    begin := start := now.
    ticks := 0.
    [ticks < 100] whileTrue:
         [[(now := Delay millisecondClockValue) = start] whileTrue.
         start := now.
         ticks := ticks + 1].
    end := now.
    (end - begin / ticks) asFloat.

gives 1.0.  (Even higher res can be obtained using
KernelLibrary>>queryPerformanceCounter:)

> Richard A. Harmon          "The only good zombie is a dead zombie"

    -- chris

[hidden email] (Richard A. Harmon) writes:
First, I vote for DateTime, as DateAndTime is just too ugly.

Second, perhaps Duration should allow us to think in terms of Months as well.
Something like:

Duration instance variables:
        months          <number>        months long
        seconds         <number>        seconds long

and the duration is the sum of the two, with the months instance variable
always used first.  So a duration of 2 years and 5 days would have months = 2
and seconds = 432,000 (5 * 86,400).  When adding

aDateTime + aDuration

you would first add the months to aDateTime and then the seconds.

I added comp.lang.smalltalk to the Newsgroups list since this issue is not
limited to Dolphin.
--
Jeff Hallman          [hidden email]

Jeffrey,

> First, I vote for DateTime, as DateAndTime is just too ugly.

Agreed, but it's too late now to do anything about it (until the next ANSI
round?)

> Second, perhaps Duration should allow us to think in terms of Months as
> well.

That wouldn't work - how long is a month?.  You would need to specify a
value in days or else things like (m:d:h:m:s) 2:30:0:0:0 + 0:1:0:0:0 would
be ambiguous. Should the answer be 3:1:0:0:0 or 2:31:0:0:0. If you do make a
decision on 30 days per month (say) then that buggers up the addition of
Duration to DateAndTime. I shan't even mention February and it's 28 (29)
days.

Having days as part of a Duration is fair enough, although I thought it
was a bit strange at first. As Chris said earlier, it helps to reinforce the
fact that Durations are not just the h:m:s in a day (as in the old Time
class) but represent _any_ period of time.

Ian

I tried to send this from my home machine but it seems not to have made it.

Ian Bartholomew wrote:
No, I mean that adding a month to Jan 31 gets you Feb 28 (or 29 in leap
years). I don't presume there are 30 days in a month: I go by the actual
calendar.  This is why I specified the ordering of months first, then
seconds.

Days and weeks are integral multiples of seconds, but months are not,
due to the varying number of days in the months.  Quarters, years,
decades, etc. are integral multiples of months.  So you need both.
End-of-month dates are special.  Check out how spreadsheet dates work.
If I add a month to April 29, I get May 29, but if I add a month to
April 30, I get May 31, since that is the end of the month.

So, what if I add one month and one day (86400 seconds) to April 29?
Following the "months first, then seconds" rule gets you to May 30.  If you
instead add seconds first, then months, you get May 31.

With this machinery and a bit of cleverness, you could create methods
such as seconds, hours, days, weeks, months, etc. in Number that return
Durations, and then write code like:

aug31 := (DateTime yyyymmdd: 20010629) +  1 days + 2 months.
oct14 := (DateTime yyyymmdd: 20010629) - 15 days + 4 months.

We need 2 subtraction operators for DateTime, one considers only seconds
(i.e. Julian dates) and another that considers months first, then
seconds.  Let's use '-' for a 'seconds only' Duration result, and '\-'
for a Duration with the maximal number of months and a remander of less
than 31 days. So we'd have

durationOf44Days := oct14 - aug31.
durationOfOneMonthAndTwoWeeks := oct14 \- aug31.

I don't know if anyone has ever done date arithmetic like this in code,
but it is the way we do it in everyday language, and it does lend itself
to natural-looking code.

--
Jeff Hallman          [hidden email]

On Mon, 2 Jul 2001 13:55:00 +0100, "Chris Uppal"
<[hidden email]> wrote:
[snip]
>As far as implementing it goes, the only ways of providing the guarantee
>that the standard mentions requires that you have access to the underlying
>implementation of the #now method.
[snip]
>Use a loop like the one that Elliot posted to c.l.s to *measure* the
>resolution of the clock.  This is portable but you loose the guarantee.  BTW
>I'd go around the loop more than once for extra reliability.  Since the
>"guarantee" required by the standard isn't actually achievable or relevant
>in practice (since the intent of the method is to provide info about the
>resolution of the clock, not to provide guarantees about the way it ticks),
>I'd not worry about that.  This is probably the best you can do portably.
>
[snip]

Thanks for the excellent explanation.  I think I better understand now
what the standard is asking for.

A lot of folks have managed to give me good answers to my garbled ANSI
questions.  I could see what Elliot's code was doing but I couldn't
reconcile it with the vague notions I had that garbage collection
would interfere with the guarantee.


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

Jeffrey,

> I don't know if anyone has ever done date arithmetic like this in code,
> but it is the way we do it in everyday language, and it does lend itself
> to natural-looking code.

OK. I can see what you are saying but I have to disagree that the Duration
class should be used in this way. An instance of the Duration class
specifies a duration of time containing a given number of seconds (or
fractions thereof). It has creation and accessor methods that allow the
period of time that the instance represents to be viewed in more user
friendly terms - days hours minutes and seconds. Because there is no set
number of seconds associated with a "month" the only way you could include
this behaviour is (as you suggested) to add some state to Duration,
completely unconnected with the seconds aspect, that maintained the month
count. To me that seems ugly, out of place and extremely prone to confusion.

I can see that there might be some value in the scheme you suggest but I
don't think that making the DateAndTime and Duration protocols support it is
going the right way about it. I would have thought that separate Date and
DateDuration classes that can recognise, and work in, periods of  months,
quarters or whatever might be better.  I can see a lot of questions about
how it would work though.

Regards
    Ian

Hi,

If you're thinking about duration classes then also consider using a rule
book that holds the date addition rules.
I've used something like this before to allow date calculation that
considered holidays, weekends, etc. for a
banking application.  e.g. In banking it's common to have to allow for
holidays across multiple countries when
determining a forward date for an FX trade and the holiday calendar and date
rolling functions wrapped in a rule book
make life a little easier.
eg.
    aDate add: duration using: aRuleBook

I suspect that there are patterns books out there that describe this better
than I am able to.  If anyone's interested, email me direct
(after removing the SPAM blocker in the return address).

Regards
Ross


"Ian Bartholomew" <[hidden email]> wrote in message
news:8Ln07.139$zJ1.9378@wards... confusion.
>
> I can see that there might be some value in the scheme you suggest but I
> don't think that making the DateAndTime and Duration protocols support it
is

Ian Bartholomew <[hidden email]> wrote in message
news:8Ln07.139$zJ1.9378@wards... confusion.
>
> I can see that there might be some value in the scheme you suggest but I
> don't think that making the DateAndTime and Duration protocols support it
is
> going the right way about it. I would have thought that separate Date and
> DateDuration classes that can recognise, and work in, periods of  months,
> quarters or whatever might be better.  I can see a lot of questions about
> how it would work though.
>
Unfortunately, the simple approach which only allows durations that can be
represented by fixed multiples of seconds has a very limited (in my
experience) use in many domains. In several business domains where I've
worked (Insurance, Credit Cards, Billing systems,...) the most important
durations, by far, are months and years. Neither months nor years are fixed
multiples of seconds.

Does it say in the ANSI spec the only state valid in a Duration is a number
of seconds? I hope not, because if months, quarters, and years can't be
added and subtracted, then I'll have to stick with the Duration and
TimeStamp classses we already have which do support them.

I can't ever remember an occasion where I needed to add a year and so many
hours to a TimeStamp (DateAndTime is definitely an ugly name). Usually I'm
either using one of the longer 'indeterminate' durations (years, months,
years and days, years and months, months and days, ...) or one of the
shorter 'determinate' durations (days, days and hours, minutes, minutes and
seconds, weeks, ...). I don't want to have to work with two sets of classes
and interfaces, however.

The TimeStamp and Duration classes I use work much like Jeffrey suggested:
the longer indeterminate durations are evaluated before the shorter ones. If
an indeterminate duration must be converted to a determinate one (asSeconds)
we use an average value such as 30 days in a month. In the context of
Duration arithmetic against a TimeStamp, however, the indeterminate Duration
is converted exactly. Our TimeStamps are also always in Universal
Coordinated Time (UTC), allowing us to convert them to a user specified
timezone for display.

Doug Swartz
[hidden email]

Doug,

> Does it say in the ANSI spec the only state valid in a Duration is a
> number of seconds? I hope not, because if months, quarters, and
> years can't be added and subtracted, then I'll have to stick with the
> Duration and TimeStamp classses we already have which do support
> them.

The ANSI spec defines Duration factory as having two constructors -

#seconds: - where the argument can be any positive or negative Number
#days:hours:minutes:seconds: - where each individual argument can be a
positive or negative Number

There are no other constructors available and therefore no way of specifying
a Duration in anything other than a specific period of time. The spec also
defines an accessor, #asSeconds, which answers the number of seconds that a
Duration instance represents.

So to answer your question. No, the ANSI spec does not allow for arbitrary
periods for the Duration classes. This also implies that a standard
DateAndTime cannot either as a lot of D&T arithmetic answers a Duration as
an argument/answer.

> I can't ever remember an occasion where I needed to add a year and so many
> hours to a TimeStamp (DateAndTime is definitely an ugly name). Usually I'm
> either using one of the longer 'indeterminate' durations (years, months,
> years and days, years and months, months and days, ...) or one of the
> shorter 'determinate' durations (days, days and hours, minutes, minutes
> and seconds, weeks, ...). I don't want to have to work with two sets of
> classes and interfaces, however.

The ANSI classes are just define a minimum framework so there is obviously
nothing to stop you adding methods that can work in the way you want. I
wouldn't think it too difficult for D&T but I don't think the Duration class
will be too easy. Depends on exactly what you want I suppose.

Ian

Doug Swartz wrote:

No uglier than Timestamp. And I like DateAndTime better than DateTime.  I
probably like my own name better but even that one does not thrill me
PointInTime.

I have had need to add hours to times stamps.  This is not unusual for schedule
and alarm mechanisms.

I would like to see this other classes if possible.  I just wrote something
similar.  And I found that for my needs storing the timestamp in local time not
gmt produced less conversion.  Basically speaking, almost always the time stamp
is displayed and compared based on its local time.  Rarely on its GMT time.

>
>
> Doug Swartz
> [hidden email]

Chris Lopeman <[hidden email]> wrote in message
news:[hidden email]...
>
>
> Doug Swartz wrote:
<snipped>
>
> > I can't ever remember an occasion where I needed to add a year and so
many
> > hours to a TimeStamp (DateAndTime is definitely an ugly name).
>
> No uglier than Timestamp. And I like DateAndTime better than DateTime.  I
> probably like my own name better but even that one does not thrill me
> PointInTime.
>
> I have had need to add hours to times stamps.  This is not unusual for
schedule
> and alarm mechanisms.
>

Yes, adding hours is common; Adding a year and some hours is uncommon.

<snipped>
> >
> > The TimeStamp and Duration classes I use work much like Jeffrey
suggested:
> > the longer indeterminate durations are evaluated before the shorter
ones. If
> > an indeterminate duration must be converted to a determinate one
(asSeconds)
> > we use an average value such as 30 days in a month. In the context of
> > Duration arithmetic against a TimeStamp, however, the indeterminate
Duration
> > is converted exactly. Our TimeStamps are also always in Universal
> > Coordinated Time (UTC), allowing us to convert them to a user specified
> > timezone for display.
>
> I would like to see this other classes if possible.  I just wrote
something
> similar.  And I found that for my needs storing the timestamp in local
time not
> gmt produced less conversion.  Basically speaking, almost always the time
stamp
> is displayed and compared based on its local time.  Rarely on its GMT
time.

Unfortunately, the classes can't be shared. Actually, they're not that
beautiful and could definitely use some refactoring, but they work fine and
hardly ever get changed.

You're right that timeStamps almost always get displayed in local time. We
decided for comparisons and sorting purposes to use UCT. We wanted audit
trails to always be 'stamped' 'in order' regardless of which time zone work
was done from and to only worry about the various world-wide daylight
savings time rules at display time. If our time stamps were in local time we
would still have to do a conversion of some sort anyway to handle the 'time
goes backwards' problem for the night when daylight savings time ends.

Doug

Ian, Richard,

What is the status with your implementation of DateAndTime
and Duration ?

Next week I have a few time to work on this.
How can I help ?
Peraps I can make some unit testing on your work.

Have a nice day.
Alain