Comparing floating-point numbers is perfectly well defined.
Floating point NUMBERS are precise.
Floating point OPERATIONS are approximate.
(See for example the LIA-1 standard.)

In the same way, comparing timestamps *from the same source*
is perfectly well defined.
Considering that light travels 30 cm (1 foot) in 1 nanosecond,
events occurring inside a single laptop are far enough apart
that recording times to nanosecond precision is questionable.
The problem is not Pharo, it's Physics.

Considering also operating system jitter, I decided that
millisecond resolution was good enough for my own library.

Now to another issue.
In Pharo 9, a DateAndTime contains
��- a julianDayNumber
��- a count of seconds
��- a count of nanos(econds)
��- a time zone offset (which is a Duration).
Converting everything *except* the zone offset to a number
is trivial, using #asNanoSeconds (which breaks the Smalltalk
naming rules; nanoseconds, being a single word, should not have
an internal capital).�� Sadly, there is no corresponding
DateAndTIme fromNanoSeconds: ns [offset: aDuration]
but it is easy enough to clone #fromSeconds:[offset:] and adapt
them.�� The reason I'm NOT going to do that is that if you do
not preserve the offset, you are STILL losing information.

What you need to do is to use a string, not a number:
�� stringForDB := aDateAndTime printString.
�� aDateAndTime := DateAndTime readFrom: stringFromDB.




On Mon, 15 Jun 2020 at 18:07, Trygve Reenskaug <trygver@ifi.uio.no> wrote:
Isn't time represented as numbers like floats; it is meaningless to test for equality. It's only meaningful to test for equality within a tolerance. This gives the, possibly unexpected, �� != �� (pi != pi).
The reason is that the first pi could be 3.14 while the second could be 3.14159265358979 ---- and the second is, of course, far from accurate.

On 2020.06.15 06:44, Jeff Gray wrote:
Hi all.
In Playground I write these lines:

Transcript cr; show: DateAndTime now printString.
Transcript cr; show: (DateAndTime fromSeconds: (DateAndTime now asSeconds))
printString.

and in the Transcript window I get these results:

2020-06-15T14:33:06.630367+10:00
2020-06-15T14:33:06+10:00

I was expecting these two to be the same.

I was hoping to use DateAndTime fromSeconds: and aDateAndTime asSeconds to
convert a DateAndTime to/from a number in order to store it in SQLite, but I
don't like the way the nanos are dropped using this method.
It's all good if I remember to call DateAndTime now truncated, and drop the
nanos myself, but that might be all over the place in my application.

Instead, is there a better way to convert a DateAndTime to and from a
number?  



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

--

The essence of object orientation is that objects collaborate�� to achieve a goal.
Trygve Reenskaug������������mailto: trygver@ifi.uio.no
Morgedalsvn. 5A��������������http://folk.uio.no/trygver/
N-0378 Oslo��������������������������http://fullOO.info
Norway������������������������������������������Tel: (+47) 468 58 625