June 2020 - Pharo-users - lists.pharo.org

Re: [Pharo-users] DateTime now nanos

by Jeff Gray

Thanks Pierce. I thought I had to transform them myself. Need to play more... -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

June 17, 2020

Re: [Pharo-users] DateTime now nanos

by Pierce Ng

On Mon, Jun 15, 2020 at 01:23:06AM -0500, Jeff Gray wrote: > Maybe I should just be asking what people normally do to store dates in > SQLite. (I'm guessing there aren't that many...) The Pharo SQLite binding stores DateAndTime instances as strings. When fetching from the database, if the declared column type looks date/time-ish then that string is turned back into a DateAndTime instance. See this blog post: https://www.samadhiweb.com/blog/2015.04.09.nbsqlite3.datetime.html The blog post refers to NBSQLite3Connection, which is for the Pharo 4 NativeBoost FFI version. Current version is here: https://github.com/pharo-rdbsm/Pharo-SQLite3 I've entertained the idea of making it pluggable, so that the application programmer gets to decide whether to store/fetch Unix epoch integers, Julian day floats, etc. No action, daydreaming only. Pierce

June 16, 2020

Re: [Pharo-users] DateTime now nanos

by Jeff Gray

Wow thanks all. Interesting topic. I think the short answer I can glean here is use a string. I wasn't sure as the SQLite doco suggested either string or number and number felt the right thing to choose. Clearly not :-) -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

June 15, 2020

Re: [Pharo-users] DateTime now nanos

by Richard O'Keefe

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

June 15, 2020

Re: [Pharo-users] DateTime now nanos

by Sven Van Caekenberghe

Hi Jeff, > On 15 Jun 2020, at 09:08, Jeff Gray <jeff(a)rogerthedog.com> wrote: > > Thanks Steph. > > Running a similar experiment using ZTimestamp: > > |ts1 ts2| > ts1 := ZTimestamp now. > tsNumber := ts1 asUnixTime. > ts2 := ZTimestamp fromUnixTime: tsNumber. > Transcript cr; show: ts1. > Transcript cr; show: ts2. > > I get the output: > 2020-06-15T07:05:59Z > 2020-06-15T07:05:59Z That is because ZTimestamp, by design, has second precision. To come back to your original question, it is not so simple to represent a timestamp as a single number. This is typically done by computing the distance to a so called epoch (reference). And you have to take the desired precision into account. You could do something like | epoch now integer timestamp | epoch := DateAndTime year: 2000 month: 1 day: 1 hour: 0 minute: 0 second: 0 nanoSecond: 0 offset: Duration zero. now := DateAndTime now. integer := (now - epoch) asNanoSeconds. timestamp := epoch + integer nanoSeconds. This works, but loses the timezone offset. That is why most databases use a string representation. For example using the tool that StÃ©phane described. For example, P3, the PostgreSQL client uses the ISO 8601 format YYYY-MM-DDThh:mm:ss.s+ZZ:zz HTH, Sven

June 15, 2020

Re: [Pharo-users] DateTime now nanos

by Jeff Gray

Thanks Steph. Running a similar experiment using ZTimestamp: |ts1 ts2| ts1 := ZTimestamp now. tsNumber := ts1 asUnixTime. ts2 := ZTimestamp fromUnixTime: tsNumber. Transcript cr; show: ts1. Transcript cr; show: ts2. I get the output: 2020-06-15T07:05:59Z 2020-06-15T07:05:59Z -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

June 15, 2020

Re: [Pharo-users] DateTime now nanos

by StÃ©phane Ducasse

Hi jeff I do not have the exact answer and too busy now. My impression that is printString is not what we want. I want a ( DatePrinter on: DateAndTime now) printIso; noMicrosecond; noTimezone; print Because your printString will certainly not work with my needs? Now I got no time to work on this but this would be a great project. So instead of bloating dateAndTime and friends I would separate it. Did you have a look at the ZTimeStamp project of Sven? Because I remember he got some facilities but my memory is to vage. S. > On 15 Jun 2020, at 06:44, Jeff Gray <jeff(a)rogerthedog.com> 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 > -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

June 15, 2020

Re: [Pharo-users] DateTime now nanos

by Jeff Gray

I expect you are right. I generally won't be looking for an exact match, even down to time. Maybe a date match, but yes more often it would be greater than less than etc. Maybe I should just be asking what people normally do to store dates in SQLite. (I'm guessing there aren't that many...) -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

June 15, 2020

Re: [Pharo-users] DateTime now nanos

by Jeff Gray

I know what you mean although with something as ubiquitous as a date, which may be initiated from a ui control, or initialised to now, or some other date, like now, or midnight etc, I wouldn't expect to wrap that up in anything. It's hard to say as I'm just working on a persistence layer right now, so maybe I shouldn't worry about it until I have some concrete examples that cause issues. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

June 15, 2020

Re: [Pharo-users] DateTime now nanos

by Trygve Reenskaug

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 collaborateto achieve a goal. / Trygve Reenskaug mailto: trygver(a)ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info NorwayÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Tel: (+47) 468 58 625

June 15, 2020