Smalltalk - Re: DateTime now nanos

Smalltalk › Pharo › Pharo Smalltalk Users

Re: DateTime now nanos

Posted by Richard O'Keefe on Jun 15, 2020; 12:21pm
URL: https://forum.world.st/DateTime-now-nanos-tp5118503p5118530.html

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 <[hidden email]> 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      [hidden email]
Morgedalsvn. 5A       http://folk.uio.no/trygver/
N-0378 Oslo             http://fullOO.info
Norway                     Tel: (+47) 468 58 625