Date and Timestamp comparison

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
68 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Date and Timestamp comparison

Boris Popov, DeepCove Labs (SNN)
Hmm,

june23ts := Timestamp fromSeconds: 3328473600.
june26dt := june23ts asDate addDays: 3.
june26dt < june23ts "false"
june26dt > june23ts "false"

Shouldn't this either blow up or actually do the right thing? It does
neither at the moment, which manifests in very subtle bugs on occasion.
Joerg tells me there's even an AR for this somewhere from a while back.

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Date and Timestamp comparison

Paul Baumann
IMO, it should do the "right thing". Given that june26dt is three days
ahead of june23ts...

 "june26dt < june23ts" should return false for the same reason that "4 <
4.0" returns false.
 "june26dt > june23ts" should return true for the same reason that "4 >
4.0" returns false.
 "june26dt = june23ts" should return false for the same reason that "4 =
4.0" returns true.

The date should be coerced to a Timestamp for comparison. #coerce: is
currently defined for ArithmaticValue. #coerce: isn't well suited for
most other subclasses of Magnitude so I propose adding the class
Chronometric as a subclass of Magnitude. Chronometric would support
coersion and be the superclass of all Date/Time classes. A generic
description of a Chronometric is 'a number of standard and deterministic
increments of a given precision from an epoch'. Coersion would be toward
the highest precision and coersion would adjust for epoch differences.
"Standard increments" means increments adjusted to GMT/UTC (when
relevant to a chronometic being compared). "Deterministic increments"
means leap durations do not cause duplication (when relevant to a
chronometic being compared). If standard/deterministic increments are
expected of one chronometic but are not known by another then the later
would convert using the current timezone and ignoring leap durations.
Standard chronometric conversion methods would make it easy to create
and compare new subclasses with little hassle.

The workaround is to do explicit coersion like this:
 june26dt asTimestamp < june23ts asTimestamp. "false"
 june26dt asTimestamp > june23ts asTimestamp. "true"
 june26dt asTimestamp = june23ts asTimestamp. "false"

Paul Baumann

-----Original Message-----
From: Boris Popov [mailto:[hidden email]]
Sent: Thursday, July 27, 2006 11:05 AM
To: [hidden email]
Subject: Date and Timestamp comparison

Hmm,

june23ts := Timestamp fromSeconds: 3328473600.
june26dt := june23ts asDate addDays: 3.
june26dt < june23ts "false"
june26dt > june23ts "false"

Shouldn't this either blow up or actually do the right thing? It does
neither at the moment, which manifests in very subtle bugs on occasion.
Joerg tells me there's even an AR for this somewhere from a while back.

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message header.
Unless otherwise indicated, it contains information that is private and
confidential. If you have received it in error, please notify the sender
and delete the entire message including any attachments.

Thank you.
 
 
 
--------------------------------------------------------
This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.  
 

Reply | Threaded
Open this post in threaded view
|

RE: Date and Timestamp comparison

Boris Popov, DeepCove Labs (SNN)
I agree, it should just coerce them automagically. Also, as far as your
suggestion to do the coercion by hand, clearly that's the way to do it,
unfortunately often you come across code which you would not suspect as
being of disperate types, and therefore subtle bugs are introduced.

self documents reject: [:ea | ea received > self deadline]

where #received could be a timestamp and #deadline could be a date.

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: Paul Baumann [mailto:[hidden email]]
Sent: Thursday, July 27, 2006 11:31 AM
To: Boris Popov; [hidden email]
Subject: RE: Date and Timestamp comparison

IMO, it should do the "right thing". Given that june26dt is three days
ahead of june23ts...

 "june26dt < june23ts" should return false for the same reason that "4 <
4.0" returns false.
 "june26dt > june23ts" should return true for the same reason that "4 >
4.0" returns false.
 "june26dt = june23ts" should return false for the same reason that "4 =
4.0" returns true.

The date should be coerced to a Timestamp for comparison. #coerce: is
currently defined for ArithmaticValue. #coerce: isn't well suited for
most other subclasses of Magnitude so I propose adding the class
Chronometric as a subclass of Magnitude. Chronometric would support
coersion and be the superclass of all Date/Time classes. A generic
description of a Chronometric is 'a number of standard and deterministic
increments of a given precision from an epoch'. Coersion would be toward
the highest precision and coersion would adjust for epoch differences.
"Standard increments" means increments adjusted to GMT/UTC (when
relevant to a chronometic being compared). "Deterministic increments"
means leap durations do not cause duplication (when relevant to a
chronometic being compared). If standard/deterministic increments are
expected of one chronometic but are not known by another then the later
would convert using the current timezone and ignoring leap durations.
Standard chronometric conversion methods would make it easy to create
and compare new subclasses with little hassle.

The workaround is to do explicit coersion like this:
 june26dt asTimestamp < june23ts asTimestamp. "false"
 june26dt asTimestamp > june23ts asTimestamp. "true"
 june26dt asTimestamp = june23ts asTimestamp. "false"

Paul Baumann

-----Original Message-----
From: Boris Popov [mailto:[hidden email]]
Sent: Thursday, July 27, 2006 11:05 AM
To: [hidden email]
Subject: Date and Timestamp comparison

Hmm,

june23ts := Timestamp fromSeconds: 3328473600.
june26dt := june23ts asDate addDays: 3.
june26dt < june23ts "false"
june26dt > june23ts "false"

Shouldn't this either blow up or actually do the right thing? It does
neither at the moment, which manifests in very subtle bugs on occasion.
Joerg tells me there's even an AR for this somewhere from a while back.

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message header.
Unless otherwise indicated, it contains information that is private and
confidential. If you have received it in error, please notify the sender
and delete the entire message including any attachments.

Thank you.
 
 
 
--------------------------------------------------------
This message may contain confidential information and is intended for
specific recipients unless explicitly noted otherwise. If you have reason to
believe you are not an intended recipient of this message, please delete it
and notify the sender. This message may not represent the opinion of
IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and
does not constitute a contract or guarantee. Unencrypted electronic mail is
not secure and the recipient of this message is expected to provide
safeguards from viruses and pursue alternate means of communication where
privacy or a binding message is desired.  
 

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Date and Timestamp comparison

Thomas Brodt
There could however be differences in comparison of mixed date and timestamp with > and <.

Should the timestamp (in ISO format for i18n) 2006-01-01-12-00-00 be greater than 2006-01-01 or equal? If you want date presision,
it would be equal. If you want timestamp precision, the date should be coerced to the date with time zero and then is less than
12:00. Depends on what your intention for the tests are. And which side of the comparison should drive the coercion, left or right,
timestamp or date? Coercing towards highest precision of the two fails for date comparisons on a date and a timestamp that should
return equality for the date part.
You would also introduce floor and ceiling to timestamps, or - as we did - floor/ceilingTo: aPrecision (means, floor to 5 minutes
interval, ceiling to next full hour, ...), since for some tests a second difference doesn't matter.

So I have doubts that you can implement a general solution and won't need explicit coercion to be safe.

Just my 2c

Thomas


> -----Original Message-----
> From: Boris Popov [mailto:[hidden email]]
> Sent: Friday, July 28, 2006 2:16 AM
> To: Paul Baumann; [hidden email]
> Subject: RE: Date and Timestamp comparison
>
> I agree, it should just coerce them automagically. Also, as
> far as your
> suggestion to do the coercion by hand, clearly that's the way
> to do it,
> unfortunately often you come across code which you would not
> suspect as
> being of disperate types, and therefore subtle bugs are introduced.
>
> self documents reject: [:ea | ea received > self deadline]
>
> where #received could be a timestamp and #deadline could be a date.
>
> Cheers!
>
> -Boris
>
> --
> +1.604.689.0322
> DeepCove Labs Ltd.
> 4th floor 595 Howe Street
> Vancouver, Canada V6C 2T5
>
> [hidden email]
>
> CONFIDENTIALITY NOTICE
>
> This email is intended only for the persons named in the message
> header. Unless otherwise indicated, it contains information that is
> private and confidential. If you have received it in error, please
> notify the sender and delete the entire message including any
> attachments.
>
> Thank you.
>
> -----Original Message-----
> From: Paul Baumann [mailto:[hidden email]]
> Sent: Thursday, July 27, 2006 11:31 AM
> To: Boris Popov; [hidden email]
> Subject: RE: Date and Timestamp comparison
>
> IMO, it should do the "right thing". Given that june26dt is three days
> ahead of june23ts...
>
>  "june26dt < june23ts" should return false for the same
> reason that "4 <
> 4.0" returns false.
>  "june26dt > june23ts" should return true for the same reason
> that "4 >
> 4.0" returns false.
>  "june26dt = june23ts" should return false for the same
> reason that "4 =
> 4.0" returns true.
>
> The date should be coerced to a Timestamp for comparison. #coerce: is
> currently defined for ArithmaticValue. #coerce: isn't well suited for
> most other subclasses of Magnitude so I propose adding the class
> Chronometric as a subclass of Magnitude. Chronometric would support
> coersion and be the superclass of all Date/Time classes. A generic
> description of a Chronometric is 'a number of standard and
> deterministic
> increments of a given precision from an epoch'. Coersion
> would be toward
> the highest precision and coersion would adjust for epoch differences.
> "Standard increments" means increments adjusted to GMT/UTC (when
> relevant to a chronometic being compared). "Deterministic increments"
> means leap durations do not cause duplication (when relevant to a
> chronometic being compared). If standard/deterministic increments are
> expected of one chronometic but are not known by another then
> the later
> would convert using the current timezone and ignoring leap durations.
> Standard chronometric conversion methods would make it easy to create
> and compare new subclasses with little hassle.
>
> The workaround is to do explicit coersion like this:
>  june26dt asTimestamp < june23ts asTimestamp. "false"
>  june26dt asTimestamp > june23ts asTimestamp. "true"
>  june26dt asTimestamp = june23ts asTimestamp. "false"
>
> Paul Baumann
>
> -----Original Message-----
> From: Boris Popov [mailto:[hidden email]]
> Sent: Thursday, July 27, 2006 11:05 AM
> To: [hidden email]
> Subject: Date and Timestamp comparison
>
> Hmm,
>
> june23ts := Timestamp fromSeconds: 3328473600.
> june26dt := june23ts asDate addDays: 3.
> june26dt < june23ts "false"
> june26dt > june23ts "false"
>
> Shouldn't this either blow up or actually do the right thing? It does
> neither at the moment, which manifests in very subtle bugs on
> occasion.
> Joerg tells me there's even an AR for this somewhere from a
> while back.
>
> Cheers!
>
> -Boris
>
> --
> +1.604.689.0322
> DeepCove Labs Ltd.
> 4th floor 595 Howe Street
> Vancouver, Canada V6C 2T5
>
> [hidden email]
>
> CONFIDENTIALITY NOTICE
>
> This email is intended only for the persons named in the
> message header.
> Unless otherwise indicated, it contains information that is
> private and
> confidential. If you have received it in error, please notify
> the sender
> and delete the entire message including any attachments.
>
> Thank you.
>  
>  
>  
> --------------------------------------------------------
> This message may contain confidential information and is intended for
> specific recipients unless explicitly noted otherwise. If you
> have reason to
> believe you are not an intended recipient of this message,
> please delete it
> and notify the sender. This message may not represent the opinion of
> IntercontinentalExchange, Inc. (ICE), its subsidiaries or
> affiliates, and
> does not constitute a contract or guarantee. Unencrypted
> electronic mail is
> not secure and the recipient of this message is expected to provide
> safeguards from viruses and pursue alternate means of
> communication where
> privacy or a binding message is desired.  
>  
>

Reply | Threaded
Open this post in threaded view
|

RE: Date and Timestamp comparison

Joerg Beekmann, DeepCove Labs (YVR)
As Boris mentioned in the original post this has been reported
previously. See
http://www.parcplace.net/list/vwnc-archive/0305/threads.html#00032 . As

I recall an AR was created and the initial feeling was that this should
be trivial to fix. However the problem resisted a general solution and
there it was left.

Perhaps it is time to fall back to plan "B" and throw an exception when
comparing Date's and Timestamps.

Joerg



> -----Original Message-----
> From: Thomas Brodt [mailto:[hidden email]]
> Sent: July 28, 2006 12:16 AM
> To: [hidden email]
> Subject: RE: Date and Timestamp comparison
>
> There could however be differences in comparison of mixed date and
> timestamp with > and <.
>
> Should the timestamp (in ISO format for i18n) 2006-01-01-12-00-00 be
> greater than 2006-01-01 or equal? If you want date presision,
> it would be equal. If you want timestamp precision, the date should be
> coerced to the date with time zero and then is less than
> 12:00. Depends on what your intention for the tests are. And which
side of
> the comparison should drive the coercion, left or right,
> timestamp or date? Coercing towards highest precision of the two fails
for
> date comparisons on a date and a timestamp that should
> return equality for the date part.
> You would also introduce floor and ceiling to timestamps, or - as we
did -
> floor/ceilingTo: aPrecision (means, floor to 5 minutes
> interval, ceiling to next full hour, ...), since for some tests a
second
> difference doesn't matter.
>
> So I have doubts that you can implement a general solution and won't
need

> explicit coercion to be safe.
>
> Just my 2c
>
> Thomas
>
>
> > -----Original Message-----
> > From: Boris Popov [mailto:[hidden email]]
> > Sent: Friday, July 28, 2006 2:16 AM
> > To: Paul Baumann; [hidden email]
> > Subject: RE: Date and Timestamp comparison
> >
> > I agree, it should just coerce them automagically. Also, as
> > far as your
> > suggestion to do the coercion by hand, clearly that's the way
> > to do it,
> > unfortunately often you come across code which you would not
> > suspect as
> > being of disperate types, and therefore subtle bugs are introduced.
> >
> > self documents reject: [:ea | ea received > self deadline]
> >
> > where #received could be a timestamp and #deadline could be a date.
> >
> > Cheers!
> >
> > -Boris
> >
> > --
> > +1.604.689.0322
> > DeepCove Labs Ltd.
> > 4th floor 595 Howe Street
> > Vancouver, Canada V6C 2T5
> >
> > [hidden email]
> >
> > CONFIDENTIALITY NOTICE
> >
> > This email is intended only for the persons named in the message
> > header. Unless otherwise indicated, it contains information that is
> > private and confidential. If you have received it in error, please
> > notify the sender and delete the entire message including any
> > attachments.
> >
> > Thank you.
> >
> > -----Original Message-----
> > From: Paul Baumann [mailto:[hidden email]]
> > Sent: Thursday, July 27, 2006 11:31 AM
> > To: Boris Popov; [hidden email]
> > Subject: RE: Date and Timestamp comparison
> >
> > IMO, it should do the "right thing". Given that june26dt is three
days

> > ahead of june23ts...
> >
> >  "june26dt < june23ts" should return false for the same
> > reason that "4 <
> > 4.0" returns false.
> >  "june26dt > june23ts" should return true for the same reason
> > that "4 >
> > 4.0" returns false.
> >  "june26dt = june23ts" should return false for the same
> > reason that "4 =
> > 4.0" returns true.
> >
> > The date should be coerced to a Timestamp for comparison. #coerce:
is
> > currently defined for ArithmaticValue. #coerce: isn't well suited
for
> > most other subclasses of Magnitude so I propose adding the class
> > Chronometric as a subclass of Magnitude. Chronometric would support
> > coersion and be the superclass of all Date/Time classes. A generic
> > description of a Chronometric is 'a number of standard and
> > deterministic
> > increments of a given precision from an epoch'. Coersion
> > would be toward
> > the highest precision and coersion would adjust for epoch
differences.
> > "Standard increments" means increments adjusted to GMT/UTC (when
> > relevant to a chronometic being compared). "Deterministic
increments"
> > means leap durations do not cause duplication (when relevant to a
> > chronometic being compared). If standard/deterministic increments
are
> > expected of one chronometic but are not known by another then
> > the later
> > would convert using the current timezone and ignoring leap
durations.
> > Standard chronometric conversion methods would make it easy to
create

> > and compare new subclasses with little hassle.
> >
> > The workaround is to do explicit coersion like this:
> >  june26dt asTimestamp < june23ts asTimestamp. "false"
> >  june26dt asTimestamp > june23ts asTimestamp. "true"
> >  june26dt asTimestamp = june23ts asTimestamp. "false"
> >
> > Paul Baumann
> >
> > -----Original Message-----
> > From: Boris Popov [mailto:[hidden email]]
> > Sent: Thursday, July 27, 2006 11:05 AM
> > To: [hidden email]
> > Subject: Date and Timestamp comparison
> >
> > Hmm,
> >
> > june23ts := Timestamp fromSeconds: 3328473600.
> > june26dt := june23ts asDate addDays: 3.
> > june26dt < june23ts "false"
> > june26dt > june23ts "false"
> >
> > Shouldn't this either blow up or actually do the right thing? It
does

> > neither at the moment, which manifests in very subtle bugs on
> > occasion.
> > Joerg tells me there's even an AR for this somewhere from a
> > while back.
> >
> > Cheers!
> >
> > -Boris
> >
> > --
> > +1.604.689.0322
> > DeepCove Labs Ltd.
> > 4th floor 595 Howe Street
> > Vancouver, Canada V6C 2T5
> >
> > [hidden email]
> >
> > CONFIDENTIALITY NOTICE
> >
> > This email is intended only for the persons named in the
> > message header.
> > Unless otherwise indicated, it contains information that is
> > private and
> > confidential. If you have received it in error, please notify
> > the sender
> > and delete the entire message including any attachments.
> >
> > Thank you.
> >
> >
> >
> > --------------------------------------------------------
> > This message may contain confidential information and is intended
for

> > specific recipients unless explicitly noted otherwise. If you
> > have reason to
> > believe you are not an intended recipient of this message,
> > please delete it
> > and notify the sender. This message may not represent the opinion of
> > IntercontinentalExchange, Inc. (ICE), its subsidiaries or
> > affiliates, and
> > does not constitute a contract or guarantee. Unencrypted
> > electronic mail is
> > not secure and the recipient of this message is expected to provide
> > safeguards from viruses and pursue alternate means of
> > communication where
> > privacy or a binding message is desired.
> >
> >

Reply | Threaded
Open this post in threaded view
|

RE: Date and Timestamp comparison

Paul Baumann
In reply to this post by Boris Popov, DeepCove Labs (SNN)
Thomas,

You raise a valid number theory argument for which there is already an
established solution that is consistent with my proposal. I recognize
the validity of your argument but counter that all programming languages
default to intuitive and easily practiced standards. Understand that the
issue you raise exists with arithmatic values too...

It is standard behavior for coercion to be toward the greater
generality. Timestamp is a higher precision and generality than Date
just as Float is a higher generality than Integer. The standard is
required to give predictable and intuitive results. Consider how strange
things would be if ArithmaticValue assumed fuzzy variances by default
(the #asInteger or #asFloat sends below would be implied):

        4 asInteger < 4.5 asInteger. "false -- bad answer"
        4 asInteger > 4.5 asInteger. "false -- bad answer"
        4 asInteger = 4.5 asInteger. "true -- imprecise answer"

        4 asFloat < 4.5 asFloat. "true"
        4 asFloat > 4.5 asFloat. "false"
        4 asFloat = 4.5 asFloat. "false"

People expect "4 < 4.5" to return true; likewise:

2006-01-01 < 2006-01-01-12-00-00 should return true.
2006-01-01 > 2006-01-01-12-00-00 should return false.
2006-01-01 = 2006-01-01-12-00-00 should return false.

It is up to the application programmer to do fuzzy comparisons as
necessary. It could be standard that division by zero return a fuzzy
number range/limit instead of an exception, but everyone has already
been taught that division by zero has no valid result. Smalltalk can
handle fuzzy numbers and unpredictable return types, but imagine all the
confused people would be if that were the default.

With a Chronometric superclass defined and standard conversion/coercion
methods, there is nothing to prevent an application developer from
creating a FuzzyDate or FuzzyTimestamp that is a higher generality than
Timestamp and that would behave more in line with the number theory.
Consider that these answers would now be correct and predictable with
the explicit introduction of FuzzyInteger:

        4 asFuzzyInteger < 4.5. "false"
        4 asFuzzyInteger > 4.5. "false"
        4 asFuzzyInteger = 4.5. "true"

In truth, all measurements are fuzzy numbers. IMO, Science recognizes
the imprecision of those numbers in less than ideal ways due to
historical reasons, but the end results are within a margin of error
that is usually acceptable. I could go on to propose a Measurement class
hierarchy be added as a standard way to introduce fuzzy numbers to
Smalltalk, but I'll stop now.

A general solution can certainly be implemented without explicit
coercion. I consider fuzzy date comparisons to be a specialized solution
requiring explicit coercion--just as with other ArithmaticValue
comparisons.

Paul Baumann


-----Original Message-----
From: Thomas Brodt [mailto:[hidden email]]
Sent: Friday, July 28, 2006 3:16 AM
To: [hidden email]
Subject: RE: Date and Timestamp comparison

There could however be differences in comparison of mixed date and
timestamp with > and <.

Should the timestamp (in ISO format for i18n) 2006-01-01-12-00-00 be
greater than 2006-01-01 or equal? If you want date presision, it would
be equal. If you want timestamp precision, the date should be coerced to
the date with time zero and then is less than 12:00. Depends on what
your intention for the tests are. And which side of the comparison
should drive the coercion, left or right, timestamp or date? Coercing
towards highest precision of the two fails for date comparisons on a
date and a timestamp that should return equality for the date part.
You would also introduce floor and ceiling to timestamps, or - as we did
- floor/ceilingTo: aPrecision (means, floor to 5 minutes interval,
ceiling to next full hour, ...), since for some tests a second
difference doesn't matter.

So I have doubts that you can implement a general solution and won't
need explicit coercion to be safe.

Just my 2c

Thomas


> -----Original Message-----
> From: Boris Popov [mailto:[hidden email]]
> Sent: Friday, July 28, 2006 2:16 AM
> To: Paul Baumann; [hidden email]
> Subject: RE: Date and Timestamp comparison
>
> I agree, it should just coerce them automagically. Also, as far as
> your suggestion to do the coercion by hand, clearly that's the way to
> do it, unfortunately often you come across code which you would not
> suspect as being of disperate types, and therefore subtle bugs are
> introduced.
>
> self documents reject: [:ea | ea received > self deadline]
>
> where #received could be a timestamp and #deadline could be a date.
>
> Cheers!
>
> -Boris
>
> --
> +1.604.689.0322
> DeepCove Labs Ltd.
> 4th floor 595 Howe Street
> Vancouver, Canada V6C 2T5
>
> [hidden email]
>
> CONFIDENTIALITY NOTICE
>
> This email is intended only for the persons named in the message
> header. Unless otherwise indicated, it contains information that is
> private and confidential. If you have received it in error, please
> notify the sender and delete the entire message including any
> attachments.
>
> Thank you.
>
> -----Original Message-----
> From: Paul Baumann [mailto:[hidden email]]
> Sent: Thursday, July 27, 2006 11:31 AM
> To: Boris Popov; [hidden email]
> Subject: RE: Date and Timestamp comparison
>
> IMO, it should do the "right thing". Given that june26dt is three days

> ahead of june23ts...
>
>  "june26dt < june23ts" should return false for the same reason that "4

> < 4.0" returns false.
>  "june26dt > june23ts" should return true for the same reason that "4
> > 4.0" returns false.
>  "june26dt = june23ts" should return false for the same reason that "4

> = 4.0" returns true.
>
> The date should be coerced to a Timestamp for comparison. #coerce: is
> currently defined for ArithmaticValue. #coerce: isn't well suited for
> most other subclasses of Magnitude so I propose adding the class
> Chronometric as a subclass of Magnitude. Chronometric would support
> coersion and be the superclass of all Date/Time classes. A generic
> description of a Chronometric is 'a number of standard and
> deterministic increments of a given precision from an epoch'. Coersion

> would be toward the highest precision and coersion would adjust for
> epoch differences.
> "Standard increments" means increments adjusted to GMT/UTC (when
> relevant to a chronometic being compared). "Deterministic increments"
> means leap durations do not cause duplication (when relevant to a
> chronometic being compared). If standard/deterministic increments are
> expected of one chronometic but are not known by another then the
> later would convert using the current timezone and ignoring leap
> durations.
> Standard chronometric conversion methods would make it easy to create
> and compare new subclasses with little hassle.
>
> The workaround is to do explicit coersion like this:
>  june26dt asTimestamp < june23ts asTimestamp. "false"
>  june26dt asTimestamp > june23ts asTimestamp. "true"
>  june26dt asTimestamp = june23ts asTimestamp. "false"
>
> Paul Baumann
>
> -----Original Message-----
> From: Boris Popov [mailto:[hidden email]]
> Sent: Thursday, July 27, 2006 11:05 AM
> To: [hidden email]
> Subject: Date and Timestamp comparison
>
> Hmm,
>
> june23ts := Timestamp fromSeconds: 3328473600.
> june26dt := june23ts asDate addDays: 3.
> june26dt < june23ts "false"
> june26dt > june23ts "false"
>
> Shouldn't this either blow up or actually do the right thing? It does
> neither at the moment, which manifests in very subtle bugs on
> occasion.
> Joerg tells me there's even an AR for this somewhere from a while
> back.
>
> Cheers!
>
> -Boris
>
> --
> +1.604.689.0322
> DeepCove Labs Ltd.
> 4th floor 595 Howe Street
> Vancouver, Canada V6C 2T5
>
> [hidden email]
>
> CONFIDENTIALITY NOTICE
>
> This email is intended only for the persons named in the message
> header.
> Unless otherwise indicated, it contains information that is private
> and confidential. If you have received it in error, please notify the
> sender and delete the entire message including any attachments.
>
> Thank you.
>  
>  
>  
> --------------------------------------------------------
> This message may contain confidential information and is intended for
> specific recipients unless explicitly noted otherwise. If you have
> reason to believe you are not an intended recipient of this message,
> please delete it and notify the sender. This message may not represent

> the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries
> or affiliates, and does not constitute a contract or guarantee.
> Unencrypted electronic mail is not secure and the recipient of this
> message is expected to provide safeguards from viruses and pursue
> alternate means of communication where privacy or a binding message is

> desired.
>  
>
 
 
 
--------------------------------------------------------
This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.  
 

Reply | Threaded
Open this post in threaded view
|

Re: Date and Timestamp comparison

Ricardo Birmann
In reply to this post by Joerg Beekmann, DeepCove Labs (YVR)
some thoughts...

I think that the question here should really be whether it makes sense to compare a Date and a Timestamp. I am not convinced that it does, nor am I convinced that it doesn't....

I don't see why an exception could not be raised, as Joerg recommended. On the first time the code is run, the developer would notice and fix the problem accordingly to his system's business logic, i.e:

self documents reject: [:ea | ea received > self deadline]

would raise an exception and the developer would trace it and fix it to something like:

self documents reject: [:ea | ea received date > self deadline]

or:

self documents reject:
[:ea | ea received > (Timestamp fromDate: self deadline andTime: '16:00' asTime)]

OBS: '16:00' asTime works in ObjectStudio... I dont have VW installed here to check if it works in it as well, but you got the idea

Implementing a default behaviour in base classes seems to an unneeded constraint, IMHO.

Regards,

Ricardo




On 7/28/06, Joerg Beekmann <[hidden email]> wrote:
As Boris mentioned in the original post this has been reported
previously. See
http://www.parcplace.net/list/vwnc-archive/0305/threads.html#00032 . As

I recall an AR was created and the initial feeling was that this should
be trivial to fix. However the problem resisted a general solution and
there it was left.

Perhaps it is time to fall back to plan "B" and throw an exception when
comparing Date's and Timestamps.

Joerg



> -----Original Message-----
> From: Thomas Brodt [mailto:[hidden email]]
> Sent: July 28, 2006 12:16 AM
> To: [hidden email]
> Subject: RE: Date and Timestamp comparison
>
> There could however be differences in comparison of mixed date and
> timestamp with > and <.
>
> Should the timestamp (in ISO format for i18n) 2006-01-01-12-00-00 be
> greater than 2006-01-01 or equal? If you want date presision,
> it would be equal. If you want timestamp precision, the date should be
> coerced to the date with time zero and then is less than
> 12:00. Depends on what your intention for the tests are. And which
side of
> the comparison should drive the coercion, left or right,
> timestamp or date? Coercing towards highest precision of the two fails
for
> date comparisons on a date and a timestamp that should
> return equality for the date part.
> You would also introduce floor and ceiling to timestamps, or - as we
did -
> floor/ceilingTo: aPrecision (means, floor to 5 minutes
> interval, ceiling to next full hour, ...), since for some tests a
second
> difference doesn't matter.
>
> So I have doubts that you can implement a general solution and won't
need

> explicit coercion to be safe.
>
> Just my 2c
>
> Thomas
>
>
> > -----Original Message-----
> > From: Boris Popov [mailto:[hidden email]]
> > Sent: Friday, July 28, 2006 2:16 AM
> > To: Paul Baumann; [hidden email]
> > Subject: RE: Date and Timestamp comparison
> >
> > I agree, it should just coerce them automagically. Also, as
> > far as your
> > suggestion to do the coercion by hand, clearly that's the way
> > to do it,
> > unfortunately often you come across code which you would not
> > suspect as
> > being of disperate types, and therefore subtle bugs are introduced.
> >
> > self documents reject: [:ea | ea received > self deadline]
> >
> > where #received could be a timestamp and #deadline could be a date.
> >
> > Cheers!
> >
> > -Boris
> >
> > --
> > +1.604.689.0322
> > DeepCove Labs Ltd.
> > 4th floor 595 Howe Street
> > Vancouver, Canada V6C 2T5
> >
> > [hidden email]
> >
> > CONFIDENTIALITY NOTICE
> >
> > This email is intended only for the persons named in the message
> > header. Unless otherwise indicated, it contains information that is
> > private and confidential. If you have received it in error, please
> > notify the sender and delete the entire message including any
> > attachments.
> >
> > Thank you.
> >
> > -----Original Message-----
> > From: Paul Baumann [mailto:[hidden email]]
> > Sent: Thursday, July 27, 2006 11:31 AM
> > To: Boris Popov; [hidden email]
> > Subject: RE: Date and Timestamp comparison
> >
> > IMO, it should do the "right thing". Given that june26dt is three
days
> > ahead of june23ts...

> >
> >  "june26dt < june23ts" should return false for the same
> > reason that "4 <
> > 4.0" returns false.
> >  "june26dt > june23ts" should return true for the same reason
> > that "4 >
> > 4.0" returns false.
> >  "june26dt = june23ts" should return false for the same
> > reason that "4 =
> > 4.0" returns true.
> >
> > The date should be coerced to a Timestamp for comparison. #coerce:
is
> > currently defined for ArithmaticValue. #coerce: isn't well suited
for
> > most other subclasses of Magnitude so I propose adding the class
> > Chronometric as a subclass of Magnitude. Chronometric would support
> > coersion and be the superclass of all Date/Time classes. A generic
> > description of a Chronometric is 'a number of standard and
> > deterministic
> > increments of a given precision from an epoch'. Coersion
> > would be toward
> > the highest precision and coersion would adjust for epoch
differences.
> > "Standard increments" means increments adjusted to GMT/UTC (when
> > relevant to a chronometic being compared). "Deterministic
increments"
> > means leap durations do not cause duplication (when relevant to a
> > chronometic being compared). If standard/deterministic increments
are
> > expected of one chronometic but are not known by another then
> > the later
> > would convert using the current timezone and ignoring leap
durations.
> > Standard chronometric conversion methods would make it easy to
create

> > and compare new subclasses with little hassle.
> >
> > The workaround is to do explicit coersion like this:
> >  june26dt asTimestamp < june23ts asTimestamp. "false"
> >  june26dt asTimestamp > june23ts asTimestamp. "true"
> >  june26dt asTimestamp = june23ts asTimestamp. "false"
> >
> > Paul Baumann
> >
> > -----Original Message-----
> > From: Boris Popov [mailto:[hidden email]]
> > Sent: Thursday, July 27, 2006 11:05 AM
> > To: [hidden email]
> > Subject: Date and Timestamp comparison
> >
> > Hmm,
> >
> > june23ts := Timestamp fromSeconds: 3328473600.
> > june26dt := june23ts asDate addDays: 3.
> > june26dt < june23ts "false"
> > june26dt > june23ts "false"
> >
> > Shouldn't this either blow up or actually do the right thing? It
does

> > neither at the moment, which manifests in very subtle bugs on
> > occasion.
> > Joerg tells me there's even an AR for this somewhere from a
> > while back.
> >
> > Cheers!
> >
> > -Boris
> >
> > --
> > +1.604.689.0322

> > DeepCove Labs Ltd.
> > 4th floor 595 Howe Street
> > Vancouver, Canada V6C 2T5
> >
> > [hidden email]
> >
> > CONFIDENTIALITY NOTICE
> >
> > This email is intended only for the persons named in the
> > message header.
> > Unless otherwise indicated, it contains information that is
> > private and
> > confidential. If you have received it in error, please notify
> > the sender
> > and delete the entire message including any attachments.
> >
> > Thank you.
> >
> >
> >
> > --------------------------------------------------------
> > This message may contain confidential information and is intended
for

> > specific recipients unless explicitly noted otherwise. If you
> > have reason to
> > believe you are not an intended recipient of this message,
> > please delete it
> > and notify the sender. This message may not represent the opinion of
> > IntercontinentalExchange, Inc. (ICE), its subsidiaries or
> > affiliates, and
> > does not constitute a contract or guarantee. Unencrypted
> > electronic mail is
> > not secure and the recipient of this message is expected to provide
> > safeguards from viruses and pursue alternate means of
> > communication where
> > privacy or a binding message is desired.
> >
> >


Reply | Threaded
Open this post in threaded view
|

Re: Date and Timestamp comparison

Dennis smith-4
In reply to this post by Joerg Beekmann, DeepCove Labs (YVR)
A long time ago, we gave up on Date/Time etc for our business objects,
and created our own.   We do lots of comparisons -- and we have four (I think)
date types (date, hrebrewDate, dateTime, timeStamp (date/time/user/application)).
We spent lots of time on comparisons since they are important and tend to be used
quite a bit.

Its quite normal for someone to change a date into a dateTime or vice-versa, or into
a stamp.  We expect the code to continue working.

There can be issues with timezone which we support for all our date types.

I would think that these comparisons would be considered important, and such things
as reported here considered bugs -- should be fixed!

Joerg Beekmann wrote:
As Boris mentioned in the original post this has been reported
previously. See
http://www.parcplace.net/list/vwnc-archive/0305/threads.html#00032 . As 

I recall an AR was created and the initial feeling was that this should
be trivial to fix. However the problem resisted a general solution and
there it was left. 

Perhaps it is time to fall back to plan "B" and throw an exception when
comparing Date's and Timestamps.

Joerg



  
-----Original Message-----
From: Thomas Brodt [[hidden email]]
Sent: July 28, 2006 12:16 AM
To: [hidden email]
Subject: RE: Date and Timestamp comparison

There could however be differences in comparison of mixed date and
timestamp with > and <.

Should the timestamp (in ISO format for i18n) 2006-01-01-12-00-00 be
greater than 2006-01-01 or equal? If you want date presision,
it would be equal. If you want timestamp precision, the date should be
coerced to the date with time zero and then is less than
12:00. Depends on what your intention for the tests are. And which
    
side of
  
the comparison should drive the coercion, left or right,
timestamp or date? Coercing towards highest precision of the two fails
    
for
  
date comparisons on a date and a timestamp that should
return equality for the date part.
You would also introduce floor and ceiling to timestamps, or - as we
    
did -
  
floor/ceilingTo: aPrecision (means, floor to 5 minutes
interval, ceiling to next full hour, ...), since for some tests a
    
second
  
difference doesn't matter.

So I have doubts that you can implement a general solution and won't
    
need
  
explicit coercion to be safe.

Just my 2c

Thomas


    
-----Original Message-----
From: Boris Popov [[hidden email]]
Sent: Friday, July 28, 2006 2:16 AM
To: Paul Baumann; [hidden email]
Subject: RE: Date and Timestamp comparison

I agree, it should just coerce them automagically. Also, as
far as your
suggestion to do the coercion by hand, clearly that's the way
to do it,
unfortunately often you come across code which you would not
suspect as
being of disperate types, and therefore subtle bugs are introduced.

self documents reject: [:ea | ea received > self deadline]

where #received could be a timestamp and #deadline could be a date.

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: Paul Baumann [[hidden email]]
Sent: Thursday, July 27, 2006 11:31 AM
To: Boris Popov; [hidden email]
Subject: RE: Date and Timestamp comparison

IMO, it should do the "right thing". Given that june26dt is three
      
days
  
ahead of june23ts...

 "june26dt < june23ts" should return false for the same
reason that "4 <
4.0" returns false.
 "june26dt > june23ts" should return true for the same reason
that "4 >
4.0" returns false.
 "june26dt = june23ts" should return false for the same
reason that "4 =
4.0" returns true.

The date should be coerced to a Timestamp for comparison. #coerce:
      
is
  
currently defined for ArithmaticValue. #coerce: isn't well suited
      
for
  
most other subclasses of Magnitude so I propose adding the class
Chronometric as a subclass of Magnitude. Chronometric would support
coersion and be the superclass of all Date/Time classes. A generic
description of a Chronometric is 'a number of standard and
deterministic
increments of a given precision from an epoch'. Coersion
would be toward
the highest precision and coersion would adjust for epoch
      
differences.
  
"Standard increments" means increments adjusted to GMT/UTC (when
relevant to a chronometic being compared). "Deterministic
      
increments"
  
means leap durations do not cause duplication (when relevant to a
chronometic being compared). If standard/deterministic increments
      
are
  
expected of one chronometic but are not known by another then
the later
would convert using the current timezone and ignoring leap
      
durations.
  
Standard chronometric conversion methods would make it easy to
      
create
  
and compare new subclasses with little hassle.

The workaround is to do explicit coersion like this:
 june26dt asTimestamp < june23ts asTimestamp. "false"
 june26dt asTimestamp > june23ts asTimestamp. "true"
 june26dt asTimestamp = june23ts asTimestamp. "false"

Paul Baumann

-----Original Message-----
From: Boris Popov [[hidden email]]
Sent: Thursday, July 27, 2006 11:05 AM
To: [hidden email]
Subject: Date and Timestamp comparison

Hmm,

june23ts := Timestamp fromSeconds: 3328473600.
june26dt := june23ts asDate addDays: 3.
june26dt < june23ts "false"
june26dt > june23ts "false"

Shouldn't this either blow up or actually do the right thing? It
      
does
  
neither at the moment, which manifests in very subtle bugs on
occasion.
Joerg tells me there's even an AR for this somewhere from a
while back.

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the
message header.
Unless otherwise indicated, it contains information that is
private and
confidential. If you have received it in error, please notify
the sender
and delete the entire message including any attachments.

Thank you.



--------------------------------------------------------
This message may contain confidential information and is intended
      
for
  
specific recipients unless explicitly noted otherwise. If you
have reason to
believe you are not an intended recipient of this message,
please delete it
and notify the sender. This message may not represent the opinion of
IntercontinentalExchange, Inc. (ICE), its subsidiaries or
affiliates, and
does not constitute a contract or guarantee. Unencrypted
electronic mail is
not secure and the recipient of this message is expected to provide
safeguards from viruses and pursue alternate means of
communication where
privacy or a binding message is desired.


      

  

-- 
Dennis Smith                        [hidden email]
Cherniak Software Development Corporation       +1 905.771.7011
400-10 Commerce Valley Dr E                Fax: +1 905.771.6288
Thornhill, ON Canada L3T 7N7    http://www.CherniakSoftware.com
Reply | Threaded
Open this post in threaded view
|

Re: Date and Timestamp comparison

Joachim Geidel
In reply to this post by Joerg Beekmann, DeepCove Labs (YVR)
Joerg Beekmann wrote:
> Perhaps it is time to fall back to plan "B" and throw an exception when
> comparing Date's and Timestamps.

IMHO, that's the best solution in this case. Dates and timestamps are
not related in the same way as real numbers and integers are.
Mathematically, the set of integers is a subset of the set or real
numbers. But the "set of dates" is not a subset of any "set of
timestamps". This makes it impossible to define a "natural" ordering
relationship on the union of both sets, which is what the attempt to
implement polymorphic comparison methods amounts to.

You can think of the timeline as a continuous scale, and dates or
timestamps (or more generally, points in time of a certain granularity)
as "names" for time periods of a certain length (the granularity). In
this model, a date is not the same thing as a timestamp denoting the
first second (or microsecond, or whatever granularity is used for
timestamps) of the day denoted by the date. You could ask if a timestamp
preceeds a date, is included in the day denoted by a date, or is later
than a date, overlaps a timestamp of a different granularity, etc.

Another model is to think of dates and timestamps as instances on
discrete time scales of different granularity. This makes dates and
timestamps of different granularities incomparable. In SQL-92 e.g.,
values are converted to a common base granularity before comparing them.

"aDate asTimestamp" is not really a conversion, as it has the meaning
"compute a Timestamp denoting the first second/millisecond/microsecond
(?) of the day denoted by aDate". The result does not represent the same
point on the same scale, as converting 4 to 4.0 would (this conversion
converts between two representations / notations of the same thing, 4
and 4.0 are the same number from a mathematical perspective).

A lot of information on time models is available at the University of
Aalborg's TimeCenter
        http://www.cs.aau.dk/TimeCenter/pub.htm
and the "Consensus Glossary of Temporal Database Concepts"
        http://www.cs.aau.dk/~csj/Glossary/index.html
I had to dig into some of those papers some years ago when we had to
implement a full bitemporal model for a statistics application - not
exactly what I would call an easy reading... ;-)

Joachim

Reply | Threaded
Open this post in threaded view
|

Re: Date and Timestamp comparison

Travis Griggs
In reply to this post by Ricardo Birmann
On Jul 28, 2006, at 8:36, Ricardo Birmann wrote:

some thoughts...

I think that the question here should really be whether it makes sense to compare a Date and a Timestamp. I am not convinced that it does, nor am I convinced that it doesn't.... 

Or even why they would have the opportunity in the first place. This is probably overtly naive on my part, but I can't for the life of me figure out why Date or Time exist in the image with the presence of Timestamp. Just use a Timestamp to express your date.

--
Travis Griggs
Objologist
"I choose. Therefore, I Am"



DISCLAIMER: This email is bound by the terms and conditions described at http://www.key.net/disclaimer.htm

Reply | Threaded
Open this post in threaded view
|

Re: Date and Timestamp comparison

Ricardo Birmann
In reply to this post by Joachim Geidel


On 7/28/06, Joachim Geidel <[hidden email]> wrote:
Joerg Beekmann wrote:
> Perhaps it is time to fall back to plan "B" and throw an exception when
> comparing Date's and Timestamps.

IMHO, that's the best solution in this case. Dates and timestamps are
not related in the same way as real numbers and integers are.
Mathematically, the set of integers is a subset of the set or real
numbers. But the "set of dates" is not a subset of any "set of
timestamps". This makes it impossible to define a "natural" ordering
relationship on the union of both sets, which is what the attempt to
implement polymorphic comparison methods amounts to.

exactly! you can't think of a Date as a Timestamp with time 00:00, 12:00, or anything else for that matter... it is simply undefined

 

You can think of the timeline as a continuous scale, and dates or
timestamps (or more generally, points in time of a certain granularity)
as "names" for time periods of a certain length (the granularity). In
this model, a date is not the same thing as a timestamp denoting the
first second (or microsecond, or whatever granularity is used for
timestamps) of the day denoted by the date. You could ask if a timestamp
preceeds a date, is included in the day denoted by a date, or is later
than a date, overlaps a timestamp of a different granularity, etc.

Another model is to think of dates and timestamps as instances on
discrete time scales of different granularity. This makes dates and
timestamps of different granularities incomparable. In SQL-92 e.g.,
values are converted to a common base granularity before comparing them.

"aDate asTimestamp" is not really a conversion, as it has the meaning
"compute a Timestamp denoting the first second/millisecond/microsecond
(?) of the day denoted by aDate". The result does not represent the same
point on the same scale, as converting 4 to 4.0 would (this conversion
converts between two representations / notations of the same thing, 4
and 4.0 are the same number from a mathematical perspective).

A lot of information on time models is available at the University of
Aalborg's TimeCenter
         http://www.cs.aau.dk/TimeCenter/pub.htm
and the "Consensus Glossary of Temporal Database Concepts"
        http://www.cs.aau.dk/~csj/Glossary/index.html
I had to dig into some of those papers some years ago when we had to
implement a full bitemporal model for a statistics application - not
exactly what I would call an easy reading... ;-)

Joachim


Reply | Threaded
Open this post in threaded view
|

RE: Date and Timestamp comparison

Paul Baumann
In reply to this post by Boris Popov, DeepCove Labs (SNN)
It is reasonable to fix the bug by throwing an exception. How about
something like this (implemented as an ANSI exception of course):

< aDate
        aDate class == self class ifFalse: [
                ^self error: 'Date/Time comparison deficiency. Sorry
this could have been avoided if you''d purchased better tools. Fix with
explicit conversion or implement your own damn tools like everyone
else.'.
        ].
        ...

Some kidding aside, if the problem isn't to be fixed then it may be
better to throw an exception instead of allowing invalid code
assumptions to go unnoticed. Sometimes a little pain is required to get
people in order. Sometimes Smalltalk coding just isn't painful enough.
That whole polymorphism thing is overrated anyway. Real code declares
data types. Smalltalk should expect certain data types and just crash
occasionally after deployment when code or data is wrong. ;)

On second thought, fall back to plan "C" and forget the problem exists.
I'd rather get paid to write yet another DateTime implementation anyway.

Paul Baumann

P.S. This response is trying to be funny of course, not meant to offend.
I've expressed my opinion and proposed a solution that mimics common
practice. It is also common practice for application code to explicitly
compare with least common precision, but a general comparison should use
greatest common precision to yield consistent and predictable results.
It should be clear how a Chronometric abstract superclass would
facilitate conversions as well as both types of comparisions. I'll leave
the topic alone now. Cheers!


-----Original Message-----
From: Joerg Beekmann [mailto:[hidden email]]
Sent: Friday, July 28, 2006 11:13 AM
To: Thomas Brodt; [hidden email]
Subject: RE: Date and Timestamp comparison

As Boris mentioned in the original post this has been reported
previously. See
http://www.parcplace.net/list/vwnc-archive/0305/threads.html#00032 . As

I recall an AR was created and the initial feeling was that this should
be trivial to fix. However the problem resisted a general solution and
there it was left.

Perhaps it is time to fall back to plan "B" and throw an exception when
comparing Date's and Timestamps.

Joerg
 
 
 
--------------------------------------------------------
This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.  
 

Reply | Threaded
Open this post in threaded view
|

RE: Date and Timestamp comparison

Steven Kelly
In reply to this post by Boris Popov, DeepCove Labs (SNN)

From: Ricardo Birmann [mailto:[hidden email]]
Dates and timestamps are not related in the same way as

real numbers and integers are.
Mathematically, the set of integers is a subset of the set or real
numbers. …

 

exactly! you can't think of a Date as a Timestamp with time 00:00, 12:00, or anything else for that matter... it is simply undefined


"aDate asTimestamp" is not really a conversion, as it has the meaning
"compute a Timestamp denoting the first second/millisecond/microsecond
(?) of the day denoted by aDate". The result does not represent the same
point on the same scale, as converting 4 to 4.0 would (this conversion
converts between two representations / notations of the same thing, 4
and 4.0 are the same number from a mathematical perspective).

I'd like to put a different point of view on this. I agree that mathematically, 4 and 4.0 are generally regarded as being equal. But that's only one definition of equality; even in mathematics there are times when they are most definitely not the same thing. For instance 4 is also regarded as being equal to the complex number 4 + 0i, which in turn is regarded as equal to the point (4,0) in the complex plane. And under modular mathematics, modulo 3, 4 is equal to 1. I'm sure you wouldn't want all these "equals" to be the default behaviour in Smalltalk, and nor should they be.

 

In science and engineering, 4 and 4.0 are very different: the second is 10 times more accurate than the first.

 

In common experience (and also in linguistics) 4 is a measure used for countable things like apples (countable nouns), whereas 4.0 is a measure used for non-countable things like apple sauce (mass nouns). The two can't be compared directly (rather like apples and oranges), and whilst the former can exist without units, the latter needs a unit (4.0kg, 4 litres etc.). You can't apply one form of number to the other kind of thing: "we're so average, we have 2.4 kids", or "how much water is in that lake, Daddy?" "3!". Very different beasts.

 

There's thus no sound basis for making black and white statements about whether Integers and Reals, or Dates and Timestamps, are always comparable. We certainly can't use maths to tell us the answer about Dates and Timestamps – it doesn't even really give the final answer for its own domain.

 

The best basis for a decision in VW, IMHO, is what is most useful to most people who are not doing research in that particular area. In the cases above, clearly it is useful to most people to compare Integers and Reals transparently. There may be catches where we hit the limits of precision for either type, but in general things will work. Similarly for Timestamps and Dates: a Timestamp equates very well to a Real, and a Date to an Integer. If we consider a Date as having a zero Time part, just as we consider an Integer to have a zero part after the decimal point, we have a coherent system that produces intuitive results.

 

Dates and Timestamps are not numbers, but we can define a useful algebra on them, allowing operations mixing Dates and Timestamps. There's nothing in VW that says that a Date is any particular, well-defined semantic kind of date – it's just your everyday kind of date. As such everybody uses (and abuses) it in different ways. But you can be pretty sure the majority of ways would be compatible with an ordering that said 3pm on December 25th 2006 is greater than December 1st 2006. If you want to compare 3pm on December 25th 2006 with December 25th 2006, most people would say it is still greater; if you want to say they're the same, or something even more funky, you have to do a little more work (e.g. convert both to Dates first).

 

Just my tuppence…

Steve

Reply | Threaded
Open this post in threaded view
|

Re: Date and Timestamp comparison

Joachim Geidel
Steven Kelly wrote:
> The best basis for a decision in VW, IMHO, is what is most useful to
> most people who are not doing research in that particular area.

Point taken. What I wrote was quite over the top. :-(

> Dates and Timestamps are not numbers, but we can define a useful algebra
> on them, allowing operations mixing Dates and Timestamps. There's
> nothing in VW that says that a Date is any particular, well-defined
> semantic kind of date – it's just your everyday kind of date. As such
> everybody uses (and abuses) it in different ways. But you can be pretty
> sure the majority of ways would be compatible with an ordering that said
> 3pm on December 25^th 2006 is greater than December 1^st 2006. If you
> want to compare 3pm on December 25^th 2006 with December 25^th 2006,
> most people would say it is still greater; if you want to say they're
> the same, or something even more funky, you have to do a little more
> work (e.g. convert both to Dates first).

You are right, as long as it's clearly defined what the result is, this
solution would be okay in most cases. Raising an exception when
comparing Dates to Timestamps would make them harder to use, so I don't
prefer this solution any more. Whether 3pm on December 25^th 2006 should
be greater than December 25^th 2006 or not is not so important as long
as the results are consistent.

Joachim

Reply | Threaded
Open this post in threaded view
|

Pollock rant

Carl Gundel
In reply to this post by Travis Griggs
<rant>
I've been putting off posting about this for a long time, but I need to
speak up so that hopefully something will change.

This policy of not supporting Pollock is counterproductive.  The original
timetable for Pollock would have had it in production release now, and at
SIC 2005 Sam said in his presentation that Pollock was then ready to use and
he encouraged us to use it.  It looked like Pollock was exactly what I need,
and based on Sam's presentation, I thought I had good reason to think that
Pollock was actually in a state to be useful.  I actually waited until
Pollock had another release before I started my port from VisualSmalltalk.
That was in winter of 2005.

There have been all sorts of problems.  Missing behavior, horribly slow
performance, weird keyboard and mouse handling, drawing bugs, etc.  None of
this would be a big deal if the VW dev team would respond to these issues.
The "official" stance is that Pollock is in beta and unsupported.  Call it
beta or anything else you like, but a useful Pollock is overdue.  The
promise of a really great UI framework is there, but it's frustrating that
progress is terribly lacking.

I spend a lot of time trying to bend Pollock to my will.  I am not trying to
do anything special really.  My software has simple UI features.  I don't
even ask for help until I've put real time into trying to solve issues
myself.  When I finally ask for help with some problem the response is often
what I perceive to be indifference.  I get more Pollock help from people who
don't work for Cincom.  I don't have time for this.  :-/

It baffles me that there isn't some energy given to support people who are
trying to use Pollock.  How is Pollock ever supposed to become production if
the core quality isn't there?  Most software development companies would
fall over backwards to embrace early adopters.

-Fix bugs before adding features
-Only refactor the design once the core has good quality (quality meaning it
can be used to build software)
-Do something (anything) about the severe performance problems.  I have
spent time in the profiler, but I have not been able to grok why it is so
slow, but why shouldn't Cincom's developers be able to get an order of
magnitude performance improvement in half an afternoon?  A tenfold
performance boost would be tremendously helpful, although I'm sure it could
be a hundred times faster in some places.  Please ditch the "we'll optimize
it later" position.  It doesn't serve your customers well.

I love VisualWorks.  The VW development team is a great bunch of people, and
most of the time I get pretty good support.  Pollock needs the same
treatment as the rest of the product.  The current stance of non-support is
wrong and it jeapardizes the future of VW Smalltalk, at least for my
project.  I am not using the non-commercial version of VisualWorks.  I am a
paying customer.  I am not using this for some free hobby project.  This is
my livelihood.  This is my own money, time, and sweat I'm pouring into this.
If I seem distressed, this is why.
</rant>

-Carl Gundel, author of Liberty BASIC
http://www.libertybasic.com



Reply | Threaded
Open this post in threaded view
|

Re: Date and Timestamp comparison

Keith Piraino
In reply to this post by Joachim Geidel
In the code below assume #received answers a Timestamp and #due answers
a Date.

   self received > self due
      ifTrue: [self processLatePayment]

Using the coerce dates to midnight approach we end up assuming a
payment  received on the due date is late unless it happens to come at
exactly midnight. Examples like this suggest that converting the
Timestamp to a Date might be just as reasonable a default approach.
Throwing an exception also seems reasonable.

In any case I usually embed the type in the name of the variable or
method to help ensure I'm always comparing like to like. So, I'd
probably end up implementing both #receivedTimestamp and #receivedDate
and just use the date one for the comparison:

   self receivedDate > self dueDate
      ifTrue: [self processLatePayment]

- Keith

--- Joachim Geidel <[hidden email]> wrote:

> Steven Kelly wrote:
> > The best basis for a decision in VW, IMHO, is what is most useful
> to
> > most people who are not doing research in that particular area.
>
> Point taken. What I wrote was quite over the top. :-(
>
> > Dates and Timestamps are not numbers, but we can define a useful
> algebra
> > on them, allowing operations mixing Dates and Timestamps. There's
> > nothing in VW that says that a Date is any particular, well-defined
> > semantic kind of date – it's just your everyday kind of date. As
> such
> > everybody uses (and abuses) it in different ways. But you can be
> pretty
> > sure the majority of ways would be compatible with an ordering that
> said
> > 3pm on December 25^th 2006 is greater than December 1^st 2006. If
> you
> > want to compare 3pm on December 25^th 2006 with December 25^th
> 2006,
> > most people would say it is still greater; if you want to say
> they're
> > the same, or something even more funky, you have to do a little
> more
> > work (e.g. convert both to Dates first).
>
> You are right, as long as it's clearly defined what the result is,
> this
> solution would be okay in most cases. Raising an exception when
> comparing Dates to Timestamps would make them harder to use, so I
> don't
> prefer this solution any more. Whether 3pm on December 25^th 2006
> should
> be greater than December 25^th 2006 or not is not so important as
> long
> as the results are consistent.
>
> Joachim
>
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 

Reply | Threaded
Open this post in threaded view
|

Re: Pollock rant

James Robertson-3
In reply to this post by Carl Gundel
Well, this does put us in a difficult position.  Pollock is still in
preview, so it doesn't get official support.  At the same time, Sam
has been pretty responsive to input.  So far as optimization goes, I
know that Sam has a schedule for that - I've spoken to him about it.

At 12:56 PM 7/29/2006, you wrote:

><rant>
>I've been putting off posting about this for a long time, but I need to
>speak up so that hopefully something will change.
>
>This policy of not supporting Pollock is counterproductive.  The original
>timetable for Pollock would have had it in production release now, and at
>SIC 2005 Sam said in his presentation that Pollock was then ready to use and
>he encouraged us to use it.  It looked like Pollock was exactly what I need,
>and based on Sam's presentation, I thought I had good reason to think that
>Pollock was actually in a state to be useful.  I actually waited until
>Pollock had another release before I started my port from VisualSmalltalk.
>That was in winter of 2005.
>
>There have been all sorts of problems.  Missing behavior, horribly slow
>performance, weird keyboard and mouse handling, drawing bugs, etc.  None of
>this would be a big deal if the VW dev team would respond to these issues.
>The "official" stance is that Pollock is in beta and unsupported.  Call it
>beta or anything else you like, but a useful Pollock is overdue.  The
>promise of a really great UI framework is there, but it's frustrating that
>progress is terribly lacking.
>
>I spend a lot of time trying to bend Pollock to my will.  I am not trying to
>do anything special really.  My software has simple UI features.  I don't
>even ask for help until I've put real time into trying to solve issues
>myself.  When I finally ask for help with some problem the response is often
>what I perceive to be indifference.  I get more Pollock help from people who
>don't work for Cincom.  I don't have time for this.  :-/
>
>It baffles me that there isn't some energy given to support people who are
>trying to use Pollock.  How is Pollock ever supposed to become production if
>the core quality isn't there?  Most software development companies would
>fall over backwards to embrace early adopters.
>
>-Fix bugs before adding features
>-Only refactor the design once the core has good quality (quality meaning it
>can be used to build software)
>-Do something (anything) about the severe performance problems.  I have
>spent time in the profiler, but I have not been able to grok why it is so
>slow, but why shouldn't Cincom's developers be able to get an order of
>magnitude performance improvement in half an afternoon?  A tenfold
>performance boost would be tremendously helpful, although I'm sure it could
>be a hundred times faster in some places.  Please ditch the "we'll optimize
>it later" position.  It doesn't serve your customers well.
>
>I love VisualWorks.  The VW development team is a great bunch of people, and
>most of the time I get pretty good support.  Pollock needs the same
>treatment as the rest of the product.  The current stance of non-support is
>wrong and it jeapardizes the future of VW Smalltalk, at least for my
>project.  I am not using the non-commercial version of VisualWorks.  I am a
>paying customer.  I am not using this for some free hobby project.  This is
>my livelihood.  This is my own money, time, and sweat I'm pouring into this.
>If I seem distressed, this is why.
></rant>
>
>-Carl Gundel, author of Liberty BASIC
>http://www.libertybasic.com

<Talk Small and Carry a Big Class Library>
James Robertson, Product Manager, Cincom Smalltalk
http://www.cincomsmalltalk.com/blog/blogView

Reply | Threaded
Open this post in threaded view
|

RE: Pollock rant

Steven Kelly
In reply to this post by Carl Gundel
James Robertson wrote:
> Well, this does put us in a difficult position.  Pollock is still in
> preview, so it doesn't get official support.  

And since Wrapper is to be replaced, it hasn't received a normal level
of support for over four years now. Part of the problem is that
throughout those four years, Pollock has always been "going to be in
production in 12-18 months". Here's Sames from July 2002:

http://www.parcplace.net/list/vwnc-archive/0207/msg00091.html
> So, if Pollock will go into a production release in 2 - 3 releases
> (7.2 or 7.3) [as Sames said in his previous message], then that means
> something on the order of 12 - 18 months before it goes into
production.
> After that, it will sit side by side with the current GUI framework
for
> a minimum of another 2 releases (about a year... maybe a year and a
half
> if it has to go to 3 releases). Finally, the old framework will be
> removed from the base image. That is in 2 to 3 years from now.

As Ralph Johnson put it, in the same thread:
http://www.parcplace.net/list/vwnc-archive/0207/msg00076.html
> Think how long Cincom has been working on OpenTalk.
> I predict that Pollock will take longer than has been predicted.
> Also, there is a greater than 0% chance that it will never be
> finished.  I predict that the time from when it is first available
> for use to the time when you will be unhappy if you have not converted
> will be at least three years.  Finally, I predict that if you hire
> John Brant to do the conversion for you, it will take much less time
> than you thought possible.

The best thing to come out of Pollock so far, from our industry's point
of view, is Sames' superb documentation of its progress. There's a
lovely research project for some student: go through the Pollock
releases and Sames' blog and other postings, and dissect the evolution
of a framework.

I still have high hopes for Pollock: doing it is the right decision, and
Sames is doing it according to good XP practice (although it remains to
be seen how well his interpretation of some aspects like late
optimization works in the end; certainly it's been bad news so far in
that it's stopped much early adoption).

The big question I see remaining is how long will it take Cincom to
rewrite all existing VW tools in Pollock. That was stated as a
prerequisite for removing Wrapper from the base image into the obsolete
directory, where it will remain as a loadable parcel "probably almost
forever". I predict the tool migration will also take "probably almost
forever", so to calculate the time till Wrapper is removed you need to
load AT MetaNumerics:

  Transcript cr; show: (2 * (Infinity positive - 1)) printString

Steve :-)

> At 12:56 PM 7/29/2006, you wrote:
> ><rant>
> >I've been putting off posting about this for a long time, but I need
to
> >speak up so that hopefully something will change.
> >
> >This policy of not supporting Pollock is counterproductive.  The
original
> >timetable for Pollock would have had it in production release now,
and at
> >SIC 2005 Sam said in his presentation that Pollock was then ready to
use
> and
> >he encouraged us to use it.  It looked like Pollock was exactly what
I
> need,
> >and based on Sam's presentation, I thought I had good reason to think
> that
> >Pollock was actually in a state to be useful.  I actually waited
until
> >Pollock had another release before I started my port from
VisualSmalltalk.
> >That was in winter of 2005.
> >
> >There have been all sorts of problems.  Missing behavior, horribly
slow
> >performance, weird keyboard and mouse handling, drawing bugs, etc.
None
> of
> >this would be a big deal if the VW dev team would respond to these
issues.
> >The "official" stance is that Pollock is in beta and unsupported.
Call
> it
> >beta or anything else you like, but a useful Pollock is overdue.  The
> >promise of a really great UI framework is there, but it's frustrating
> that
> >progress is terribly lacking.
> >
> >I spend a lot of time trying to bend Pollock to my will.  I am not
trying
> to
> >do anything special really.  My software has simple UI features.  I
don't
> >even ask for help until I've put real time into trying to solve
issues
> >myself.  When I finally ask for help with some problem the response
is
> often
> >what I perceive to be indifference.  I get more Pollock help from
people
> who
> >don't work for Cincom.  I don't have time for this.  :-/
> >
> >It baffles me that there isn't some energy given to support people
who
> are
> >trying to use Pollock.  How is Pollock ever supposed to become
production
> if
> >the core quality isn't there?  Most software development companies
would
> >fall over backwards to embrace early adopters.
> >
> >-Fix bugs before adding features
> >-Only refactor the design once the core has good quality (quality
meaning
> it
> >can be used to build software)
> >-Do something (anything) about the severe performance problems.  I
have
> >spent time in the profiler, but I have not been able to grok why it
is so
> >slow, but why shouldn't Cincom's developers be able to get an order
of
> >magnitude performance improvement in half an afternoon?  A tenfold
> >performance boost would be tremendously helpful, although I'm sure it
> could
> >be a hundred times faster in some places.  Please ditch the "we'll
> optimize
> >it later" position.  It doesn't serve your customers well.
> >
> >I love VisualWorks.  The VW development team is a great bunch of
people,
> and
> >most of the time I get pretty good support.  Pollock needs the same
> >treatment as the rest of the product.  The current stance of
non-support
> is
> >wrong and it jeapardizes the future of VW Smalltalk, at least for my
> >project.  I am not using the non-commercial version of VisualWorks.
I am
> a
> >paying customer.  I am not using this for some free hobby project.
This
> is
> >my livelihood.  This is my own money, time, and sweat I'm pouring
into

> this.
> >If I seem distressed, this is why.
> ></rant>
> >
> >-Carl Gundel, author of Liberty BASIC
> >http://www.libertybasic.com
>
> <Talk Small and Carry a Big Class Library>
> James Robertson, Product Manager, Cincom Smalltalk
> http://www.cincomsmalltalk.com/blog/blogView

Reply | Threaded
Open this post in threaded view
|

Re: Pollock rant

Joachim Geidel
Steven Kelly wrote:
> I still have high hopes for Pollock: doing it is the right decision, and
> Sames is doing it according to good XP practice (although it remains to
> be seen how well his interpretation of some aspects like late
> optimization works in the end; certainly it's been bad news so far in
> that it's stopped much early adoption).

IMO, there's two different kinds of performance "optimization". If there
is a requirement that something executes in x milliseconds, then making
the code run fast enough such that it meets this target is not
optimization, but fixing a bug. Continuing to tune for speed when the
requirements are already fulfilled is what I would think of as
optimization.

In the case of Pollock, the comments about its performance imply that
Pollock currently does not meet an important non-functional requirement,
which would be a bug and consequently should be addressed as soon as
possible instead of being postponed. If the performance problems are
resulting from a design problem, then postponing to address them will
probably make them harder to solve.

However, if the performance requirements are not defined in an explicit
and testable way (e.g. "an open and completely visible window with 20
input fields must update in 0.1 seconds when the contents of all input
fields changes"), it's hard to draw the borderline between bug fixing
and optimization. Are Pollock's performance targets well-defined?

Best regards,
Joachim Geidel

Reply | Threaded
Open this post in threaded view
|

Re: Pollock rant

Ladislav Lenart
In reply to this post by Carl Gundel
Carl Gundel wrote:

> <rant>
> I've been putting off posting about this for a long time, but I need to
> speak up so that hopefully something will change.
>
> This policy of not supporting Pollock is counterproductive.  The original
> timetable for Pollock would have had it in production release now, and at
> SIC 2005 Sam said in his presentation that Pollock was then ready to use and
> he encouraged us to use it.  It looked like Pollock was exactly what I need,
> and based on Sam's presentation, I thought I had good reason to think that
> Pollock was actually in a state to be useful.  I actually waited until
> Pollock had another release before I started my port from VisualSmalltalk.
> That was in winter of 2005.
>
> There have been all sorts of problems.  Missing behavior, horribly slow
> performance, weird keyboard and mouse handling, drawing bugs, etc.  None of
> this would be a big deal if the VW dev team would respond to these issues.
> The "official" stance is that Pollock is in beta and unsupported.  Call it
> beta or anything else you like, but a useful Pollock is overdue.  The
> promise of a really great UI framework is there, but it's frustrating that
> progress is terribly lacking.
>
> I spend a lot of time trying to bend Pollock to my will.  I am not trying to
> do anything special really.  My software has simple UI features.  I don't
> even ask for help until I've put real time into trying to solve issues
> myself.  When I finally ask for help with some problem the response is often
> what I perceive to be indifference.  I get more Pollock help from people who
> don't work for Cincom.  I don't have time for this.  :-/
>
> It baffles me that there isn't some energy given to support people who are
> trying to use Pollock.  How is Pollock ever supposed to become production if
> the core quality isn't there?  Most software development companies would
> fall over backwards to embrace early adopters.
>
> -Fix bugs before adding features
> -Only refactor the design once the core has good quality (quality meaning it
> can be used to build software)
> -Do something (anything) about the severe performance problems.  I have
> spent time in the profiler, but I have not been able to grok why it is so
> slow, but why shouldn't Cincom's developers be able to get an order of
> magnitude performance improvement in half an afternoon?  A tenfold
> performance boost would be tremendously helpful, although I'm sure it could
> be a hundred times faster in some places.  Please ditch the "we'll optimize
> it later" position.  It doesn't serve your customers well.

I posted a problem with Pollock slowness some time ago (maybe a year ago).
At the time I digged in and made some profiling that showed that the cause
of the slowness is mainly in LayoutFrame hierarchy and form's (subcanvas)
nesting. Especially RelationalFrame is real performance killer. This is
basically because there is no caching of values. So, for example when you
click on input field to start typying, absolute bounds have to be calculated
and in case of fractional and relational frames, this takes really long,
because the same thing is computed many times (as with loosely written
Fibonacci sequence).

We also tried to fix it but it turned out not be easy (for us).
Therefore we canceled our effort to start new project with Pollock.

But these findings are dated basically a year back so I am not
sure if this is still Pollock's current performance bottleneck.

Ladislav Lenart

1234