[Pharo-project] DateAndTime and TimeStamp precision
I am noticing that both DateAndTime now TimeStamp now have a precision of seconds, that is, the nanos is always 0. I am doing a bulk data creation and inserting them in a list with a timestamp for each insertion but this isn't working because several entries have the very same DateAndTime or Timestamp. For example: {DateAndTime. TimeStamp } collect: [ :class | | list | list := OrderedCollection new. 1 to: 1000 do: [ :each | value := class now. list add: value ]. list last - list first ] gives an Array(0:00:00:00 0:00:00:00) How can achieve smaller than a second timestamping in Pharo? -- Miguel Cobá http://miguel.leugim.com.mx
I have no idea. I just remember this discussion: http://n4.nabble.com/Nanosecond-level-profiling-in-Pharo-td1296771.html#a129... 2010/2/12 Miguel Enrique Cobá Martinez <miguel.coba@gmail.com>
I am noticing that both
DateAndTime now TimeStamp now
have a precision of seconds, that is, the nanos is always 0.
I am doing a bulk data creation and inserting them in a list with a timestamp for each insertion but this isn't working because several entries have the very same DateAndTime or Timestamp.
For example:
{DateAndTime. TimeStamp } collect: [ :class | | list | list := OrderedCollection new. 1 to: 1000 do: [ :each | value := class now. list add: value ]. list last - list first ]
gives an Array(0:00:00:00 0:00:00:00)
How can achieve smaller than a second timestamping in Pharo? -- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
El vie, 12-02-2010 a las 20:08 +0100, Mariano Martinez Peck escribió:
I have no idea. I just remember this discussion:
http://n4.nabble.com/Nanosecond-level-profiling-in-Pharo-td1296771.html#a129...
Thanks I remember reading something about in the list but couldn't find it anymore. Now, by reading it, people are talking about nanoseconds granularity. I don't want that level of granularity, but only to differentiate between two consecutive calls to time1 := DateAndTime now. time2 := DateAndTime now. self assert: [ (time2 - time1) > 0 ] I really don't care the specific granularity, only to be able to distinguish the creation of two objects without using an artificial delay between both creations. Or is this something not reasonable? Or how can I timestamp a lot of objects created in a loop inside the image? cheers
2010/2/12 Miguel Enrique Cobá Martinez <miguel.coba@gmail.com> I am noticing that both
DateAndTime now TimeStamp now
have a precision of seconds, that is, the nanos is always 0.
I am doing a bulk data creation and inserting them in a list with a timestamp for each insertion but this isn't working because several entries have the very same DateAndTime or Timestamp.
For example:
{DateAndTime. TimeStamp } collect: [ :class | | list | list := OrderedCollection new. 1 to: 1000 do: [ :each | value := class now. list add: value ]. list last - list first ]
gives an Array(0:00:00:00 0:00:00:00)
How can achieve smaller than a second timestamping in Pharo? -- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
Ok, so you're complaining that your computer is too fast... :) On a more serious note, you might be happier adding a counter field, which can be as simple as the index in the collection, a field in an RDBMS, or something that you increment and save into each object you create. Oddly enough, I encountered this same problem (again) only days ago, and have gone the implied counter route. In my case, each datum gets a line in a text file, so they are naturally ordered, and I make that concrete as I re-export the data for abuse[*] in R. Bill [*] thought for the day: if you torture data hard enough, they will confess to anything. -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Miguel Enrique Cobá Martinez Sent: Friday, February 12, 2010 2:21 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] DateAndTime and TimeStamp precision El vie, 12-02-2010 a las 20:08 +0100, Mariano Martinez Peck escribió:
I have no idea. I just remember this discussion:
http://n4.nabble.com/Nanosecond-level-profiling-in-Pharo-td1296771.htm l#a1296771
Thanks I remember reading something about in the list but couldn't find it anymore. Now, by reading it, people are talking about nanoseconds granularity. I don't want that level of granularity, but only to differentiate between two consecutive calls to time1 := DateAndTime now. time2 := DateAndTime now. self assert: [ (time2 - time1) > 0 ] I really don't care the specific granularity, only to be able to distinguish the creation of two objects without using an artificial delay between both creations. Or is this something not reasonable? Or how can I timestamp a lot of objects created in a loop inside the image? cheers
2010/2/12 Miguel Enrique Cobá Martinez <miguel.coba@gmail.com> I am noticing that both
DateAndTime now TimeStamp now
have a precision of seconds, that is, the nanos is always 0.
I am doing a bulk data creation and inserting them in a list with a timestamp for each insertion but this isn't working because several entries have the very same DateAndTime or Timestamp.
For example:
{DateAndTime. TimeStamp } collect: [ :class | | list | list := OrderedCollection new. 1 to: 1000 do: [ :each | value := class now. list add: value ]. list last - list first ]
gives an Array(0:00:00:00 0:00:00:00)
How can achieve smaller than a second timestamping in Pharo? -- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
The DateAndTime class comment says: I represent a point in UTC time as defined by ISO 8601. I have zero duration. My implementation uses three SmallIntegers and a Duration: jdn - julian day number. seconds - number of seconds since midnight. nanos - the number of nanoseconds since the second. offset - duration from UTC. The nanosecond attribute is almost always zero but it defined for full ISO compliance and is suitable for timestamping. This last sentence I don't understand. Is almost zero? For me is always zero. Why it say that is suitable for timestamping if only works for timestamping with seconds granularity? Some idea? Or is just a bad class comment? -- Miguel Cobá http://miguel.leugim.com.mx
Miguel, Pharo allows you to drill down to millisecond resolution, but for your 'benchmark' that's still too coarse: {DateAndTime. TimeStamp } collect: [ :class | | list | list := OrderedCollection new. 1 to: 1000 do: [ :each | value := class millisecondClockValue. list add: value ]. list last - list first ]. I get an Array (1 1). Changing from 1000 to 100000 (hundred fold) I got #(77 141). HTH -- Cesar Rabak Em 12/02/2010 17:02, Miguel Enrique Cobá Martinez < miguel.coba@gmail.com > escreveu: I am noticing that both DateAndTime now TimeStamp now have a precision of seconds, that is, the nanos is always 0. I am doing a bulk data creation and inserting them in a list with a timestamp for each insertion but this isn't working because several entries have the very same DateAndTime or Timestamp. For example: {DateAndTime. TimeStamp } collect: [ :class | | list | list := OrderedCollection new. 1 to: 1000 do: [ :each | value := class now. list add: value ]. list last - list first ] gives an Array(0:00:00:00 0:00:00:00) How can achieve smaller than a second timestamping in Pharo? -- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
With the Mac VM 5.4b1 I have a microsecond clock. http://n4.nabble.com/microsecond-timing-for-GC-work-td1016253.html zero feedback, maybe it's too fast and you never get above 1 millisecond in testing eh? On 2010-02-12, at 12:46 PM, csrabak@bol.com.br wrote:
Miguel,
Pharo allows you to drill down to millisecond resolution, but for your 'benchmark' that's still too coarse:
{DateAndTime. TimeStamp } collect: [ :class | | list | list := OrderedCollection new. 1 to: 1000 do: [ :each | value := class millisecondClockValue. list add: value ]. list last - list first ].
I get an Array (1 1).
Changing from 1000 to 100000 (hundred fold) I got #(77 141).
HTH
-- Cesar Rabak
Em 12/02/2010 17:02, Miguel Enrique Cobá Martinez < miguel.coba@gmail.com > escreveu: I am noticing that both
DateAndTime now TimeStamp now
have a precision of seconds, that is, the nanos is always 0.
I am doing a bulk data creation and inserting them in a list with a timestamp for each insertion but this isn't working because several entries have the very same DateAndTime or Timestamp.
For example:
{DateAndTime. TimeStamp } collect: [ :class | | list | list := OrderedCollection new. 1 to: 1000 do: [ :each | value := class now. list add: value ]. list last - list first ]
gives an Array(0:00:00:00 0:00:00:00)
How can achieve smaller than a second timestamping in Pharo? -- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
El vie, 12-02-2010 a las 14:58 -0800, John M McIntosh escribió:
With the Mac VM 5.4b1 I have a microsecond clock. http://n4.nabble.com/microsecond-timing-for-GC-work-td1016253.html
zero feedback, maybe it's too fast and you never get above 1 millisecond in testing eh?
Thanks that indeed shown a difference in my machine. But, then other question, why the default implementation of DateAndTime now and TimeStamp now isn't smaller than a second. By sending now I get a DateAndTime object but by sending millesecondClockValue a get a SmallInteger representing the number of milliseconds. But there isn't in the class side of both classes and neither in Time class a method to build a DateAndTime, a TimeStamp or a Time from milliseconds. So to convert this value to a date again I will have to trunk the time to a second resolution. Is this analysis correct? Of course I could index my objects in the list with the millis number but I would be happier if I could index them with a real date object. Anyway, not that that is a show stopper, is just that when creating objects I'm assigning a creation date and I would like to find what objects are older that others created at about the same lapse, without resorting to use their position in an external data structure (i.e. the OrderedCollection, an array or the line number in a file). Thanks to everyone for the answers.
On 2010-02-12, at 12:46 PM, csrabak@bol.com.br wrote:
Miguel,
Pharo allows you to drill down to millisecond resolution, but for your 'benchmark' that's still too coarse:
{DateAndTime. TimeStamp } collect: [ :class | | list | list := OrderedCollection new. 1 to: 1000 do: [ :each | value := class millisecondClockValue. list add: value ]. list last - list first ].
I get an Array (1 1).
Changing from 1000 to 100000 (hundred fold) I got #(77 141).
HTH
-- Cesar Rabak
Em 12/02/2010 17:02, Miguel Enrique Cobá Martinez < miguel.coba@gmail.com > escreveu: I am noticing that both
DateAndTime now TimeStamp now
have a precision of seconds, that is, the nanos is always 0.
I am doing a bulk data creation and inserting them in a list with a timestamp for each insertion but this isn't working because several entries have the very same DateAndTime or Timestamp.
For example:
{DateAndTime. TimeStamp } collect: [ :class | | list | list := OrderedCollection new. 1 to: 1000 do: [ :each | value := class now. list add: value ]. list last - list first ]
gives an Array(0:00:00:00 0:00:00:00)
How can achieve smaller than a second timestamping in Pharo? -- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
Hi miguel what is the solution? I remember that I saw passing some code to support nanos but I'm not sure that it was integrated. Now let us fix it if possible. Stef On Feb 13, 2010, at 1:32 AM, Miguel Enrique Cobá Martinez wrote:
El vie, 12-02-2010 a las 14:58 -0800, John M McIntosh escribió:
With the Mac VM 5.4b1 I have a microsecond clock. http://n4.nabble.com/microsecond-timing-for-GC-work-td1016253.html
zero feedback, maybe it's too fast and you never get above 1 millisecond in testing eh?
Thanks that indeed shown a difference in my machine.
But, then other question, why the default implementation of DateAndTime now and TimeStamp now isn't smaller than a second. By sending now I get a DateAndTime object but by sending millesecondClockValue a get a SmallInteger representing the number of milliseconds.
But there isn't in the class side of both classes and neither in Time class a method to build a DateAndTime, a TimeStamp or a Time from milliseconds. So to convert this value to a date again I will have to trunk the time to a second resolution. Is this analysis correct?
Of course I could index my objects in the list with the millis number but I would be happier if I could index them with a real date object.
Anyway, not that that is a show stopper, is just that when creating objects I'm assigning a creation date and I would like to find what objects are older that others created at about the same lapse, without resorting to use their position in an external data structure (i.e. the OrderedCollection, an array or the line number in a file).
Thanks to everyone for the answers.
On 2010-02-12, at 12:46 PM, csrabak@bol.com.br wrote:
Miguel,
Pharo allows you to drill down to millisecond resolution, but for your 'benchmark' that's still too coarse:
{DateAndTime. TimeStamp } collect: [ :class | | list | list := OrderedCollection new. 1 to: 1000 do: [ :each | value := class millisecondClockValue. list add: value ]. list last - list first ].
I get an Array (1 1).
Changing from 1000 to 100000 (hundred fold) I got #(77 141).
HTH
-- Cesar Rabak
Em 12/02/2010 17:02, Miguel Enrique Cobá Martinez < miguel.coba@gmail.com > escreveu: I am noticing that both
DateAndTime now TimeStamp now
have a precision of seconds, that is, the nanos is always 0.
I am doing a bulk data creation and inserting them in a list with a timestamp for each insertion but this isn't working because several entries have the very same DateAndTime or Timestamp.
For example:
{DateAndTime. TimeStamp } collect: [ :class | | list | list := OrderedCollection new. 1 to: 1000 do: [ :each | value := class now. list add: value ]. list last - list first ]
gives an Array(0:00:00:00 0:00:00:00)
How can achieve smaller than a second timestamping in Pharo? -- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi, I think it is related to: http://code.google.com/p/pharo/issues/detail?id=982 If I remember well, there is no primitive with nano second accuracy so it is impossible to have it in real. Luc Le 13 févr. 10 à 10:46, Stéphane Ducasse a écrit :
Hi miguel
what is the solution? I remember that I saw passing some code to support nanos but I'm not sure that it was integrated. Now let us fix it if possible.
Stef
On Feb 13, 2010, at 1:32 AM, Miguel Enrique Cobá Martinez wrote:
El vie, 12-02-2010 a las 14:58 -0800, John M McIntosh escribió:
With the Mac VM 5.4b1 I have a microsecond clock. http://n4.nabble.com/microsecond-timing-for-GC-work-td1016253.html
zero feedback, maybe it's too fast and you never get above 1 millisecond in testing eh?
Thanks that indeed shown a difference in my machine.
But, then other question, why the default implementation of DateAndTime now and TimeStamp now isn't smaller than a second. By sending now I get a DateAndTime object but by sending millesecondClockValue a get a SmallInteger representing the number of milliseconds.
But there isn't in the class side of both classes and neither in Time class a method to build a DateAndTime, a TimeStamp or a Time from milliseconds. So to convert this value to a date again I will have to trunk the time to a second resolution. Is this analysis correct?
Of course I could index my objects in the list with the millis number but I would be happier if I could index them with a real date object.
Anyway, not that that is a show stopper, is just that when creating objects I'm assigning a creation date and I would like to find what objects are older that others created at about the same lapse, without resorting to use their position in an external data structure (i.e. the OrderedCollection, an array or the line number in a file).
Thanks to everyone for the answers.
On 2010-02-12, at 12:46 PM, csrabak@bol.com.br wrote:
Miguel,
Pharo allows you to drill down to millisecond resolution, but for your 'benchmark' that's still too coarse:
{DateAndTime. TimeStamp } collect: [ :class | | list | list := OrderedCollection new. 1 to: 1000 do: [ :each | value := class millisecondClockValue. list add: value ]. list last - list first ].
I get an Array (1 1).
Changing from 1000 to 100000 (hundred fold) I got #(77 141).
HTH
-- Cesar Rabak
Em 12/02/2010 17:02, Miguel Enrique Cobá Martinez < miguel.coba@gmail.com
escreveu: I am noticing that both
DateAndTime now TimeStamp now
have a precision of seconds, that is, the nanos is always 0.
I am doing a bulk data creation and inserting them in a list with a timestamp for each insertion but this isn't working because several entries have the very same DateAndTime or Timestamp.
For example:
{DateAndTime. TimeStamp } collect: [ :class | | list | list := OrderedCollection new. 1 to: 1000 do: [ :each | value := class now. list add: value ]. list last - list first ]
gives an Array(0:00:00:00 0:00:00:00)
How can achieve smaller than a second timestamping in Pharo? -- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- = = = = = = = ==================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = = = = = ====================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
El mar, 16-02-2010 a las 14:39 +0100, Luc Fabresse escribió:
Hi,
I think it is related to: http://code.google.com/p/pharo/issues/detail?id=982 If I remember well, there is no primitive with nano second accuracy so it is impossible to have it in real.
Yes, and indeed nano second accuracy is overkill for my current problem. I only want some given precision so that DateAndTime now < DateAndTime now is always true, so that can be used to order events (object creation in this case) using the date. Thanks
Luc
Le 13 févr. 10 à 10:46, Stéphane Ducasse a écrit :
Hi miguel
what is the solution? I remember that I saw passing some code to support nanos but I'm not sure that it was integrated. Now let us fix it if possible.
Stef
On Feb 13, 2010, at 1:32 AM, Miguel Enrique Cobá Martinez wrote:
El vie, 12-02-2010 a las 14:58 -0800, John M McIntosh escribió:
With the Mac VM 5.4b1 I have a microsecond clock. http://n4.nabble.com/microsecond-timing-for-GC-work-td1016253.html
zero feedback, maybe it's too fast and you never get above 1 millisecond in testing eh?
Thanks that indeed shown a difference in my machine.
But, then other question, why the default implementation of DateAndTime now and TimeStamp now isn't smaller than a second. By sending now I get a DateAndTime object but by sending millesecondClockValue a get a SmallInteger representing the number of milliseconds.
But there isn't in the class side of both classes and neither in Time class a method to build a DateAndTime, a TimeStamp or a Time from milliseconds. So to convert this value to a date again I will have to trunk the time to a second resolution. Is this analysis correct?
Of course I could index my objects in the list with the millis number but I would be happier if I could index them with a real date object.
Anyway, not that that is a show stopper, is just that when creating objects I'm assigning a creation date and I would like to find what objects are older that others created at about the same lapse, without resorting to use their position in an external data structure (i.e. the OrderedCollection, an array or the line number in a file).
Thanks to everyone for the answers.
On 2010-02-12, at 12:46 PM, csrabak@bol.com.br wrote:
Miguel,
Pharo allows you to drill down to millisecond resolution, but for your 'benchmark' that's still too coarse:
{DateAndTime. TimeStamp } collect: [ :class | | list | list := OrderedCollection new. 1 to: 1000 do: [ :each | value := class millisecondClockValue. list add: value ]. list last - list first ].
I get an Array (1 1).
Changing from 1000 to 100000 (hundred fold) I got #(77 141).
HTH
-- Cesar Rabak
Em 12/02/2010 17:02, Miguel Enrique Cobá Martinez < miguel.coba@gmail.com
escreveu: I am noticing that both
DateAndTime now TimeStamp now
have a precision of seconds, that is, the nanos is always 0.
I am doing a bulk data creation and inserting them in a list with a timestamp for each insertion but this isn't working because several entries have the very same DateAndTime or Timestamp.
For example:
{DateAndTime. TimeStamp } collect: [ :class | | list | list := OrderedCollection new. 1 to: 1000 do: [ :each | value := class now. list add: value ]. list last - list first ]
gives an Array(0:00:00:00 0:00:00:00)
How can achieve smaller than a second timestamping in Pharo? -- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- = = = = = = = ==================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = = = = = ====================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
On Feb 16, 2010, at 4:39 PM, Miguel Enrique Cobá Martinez wrote:
El mar, 16-02-2010 a las 14:39 +0100, Luc Fabresse escribió:
Hi,
I think it is related to: http://code.google.com/p/pharo/issues/detail?id=982 If I remember well, there is no primitive with nano second accuracy so it is impossible to have it in real.
Yes, and indeed nano second accuracy is overkill for my current problem. I only want some given precision so that
DateAndTime now < DateAndTime now
is always true, so that can be used to order events (object creation in this case) using the date.
I think this was removed as part of speeding up date and time because it was slowing down everything. (long time ago) And people where thinking that this is actually not true: if you ask two times for a corse-grained time, you *can* get the same time twice if you ask faster than the base resolution. It would be interesting to know how other languages handle this. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
Den 16.02.2010 16:44, skrev Marcus Denker:
On Feb 16, 2010, at 4:39 PM, Miguel Enrique Cobá Martinez wrote:
El mar, 16-02-2010 a las 14:39 +0100, Luc Fabresse escribió:
Hi,
I think it is related to: http://code.google.com/p/pharo/issues/detail?id=982 If I remember well, there is no primitive with nano second accuracy so it is impossible to have it in real.
Yes, and indeed nano second accuracy is overkill for my current problem. I only want some given precision so that
DateAndTime now < DateAndTime now
is always true, so that can be used to order events (object creation in this case) using the date.
But it's not. DateAndTime now <= DateAndTime now. If you are batching them together so close that resolution is an issue why not rewrite it to something like:
currTime:= DateAndTime now. obj Count:= 0. someLoop whileTrue: [ newObj := aClass new time: currTime+ objCount; yourself. currTime := currTime +1. ] Saves you quite a few system calls as well :)
I think this was removed as part of speeding up date and time because it was slowing down everything. (long time ago)
And people where thinking that this is actually not true: if you ask two times for a corse-grained time, you *can* get the same time twice if you ask faster than the base resolution.
It would be interesting to know how other languages handle this.
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
I think the answer is as simple as you might suspect - they don't. It doesn't really make sense to ensure now < now, so they leave it to the developer to make sure that is the case if he really needs it. F.ex.: VW uses a millisecond clock for its (default) Timestamps. It provides a microsecondValue method as well, but no default Timestamp creation method using it. Java provides currentTimeMillis() (walltime since Jan 1970, resolution OS-dependent) and nanoTime (since startup). You can't really combine the two and get a Timestamp with nanosecond precision that makes sense, so I'd say it does millisecond precision as well. Cheers, Henry
El mar, 16-02-2010 a las 18:26 +0100, Henrik Johansen escribió:
Den 16.02.2010 16:44, skrev Marcus Denker:
On Feb 16, 2010, at 4:39 PM, Miguel Enrique Cobá Martinez wrote:
El mar, 16-02-2010 a las 14:39 +0100, Luc Fabresse escribió:
Hi,
I think it is related to: http://code.google.com/p/pharo/issues/detail?id=982 If I remember well, there is no primitive with nano second accuracy so it is impossible to have it in real.
Yes, and indeed nano second accuracy is overkill for my current problem. I only want some given precision so that
DateAndTime now < DateAndTime now
is always true, so that can be used to order events (object creation in this case) using the date.
But it's not. DateAndTime now <= DateAndTime now. If you are batching them together so close that resolution is an issue why not rewrite it to something like:
currTime:= DateAndTime now. obj Count:= 0. someLoop whileTrue: [ newObj := aClass new time: currTime+ objCount; yourself. currTime := currTime +1. ]
Thank you very much! I am doing something similar to this.
Saves you quite a few system calls as well :)
I think this was removed as part of speeding up date and time because it was slowing down everything. (long time ago)
And people where thinking that this is actually not true: if you ask two times for a corse-grained time, you *can* get the same time twice if you ask faster than the base resolution.
It would be interesting to know how other languages handle this.
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
I think the answer is as simple as you might suspect - they don't. It doesn't really make sense to ensure now < now, so they leave it to the developer to make sure that is the case if he really needs it.
F.ex.: VW uses a millisecond clock for its (default) Timestamps. It provides a microsecondValue method as well, but no default Timestamp creation method using it.
Java provides currentTimeMillis() (walltime since Jan 1970, resolution OS-dependent) and nanoTime (since startup). You can't really combine the two and get a Timestamp with nanosecond precision that makes sense, so I'd say it does millisecond precision as well.
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
Den 16.02.2010 18:32, skrev Miguel Enrique Cobá Martinez:
El mar, 16-02-2010 a las 18:26 +0100, Henrik Johansen escribió:
Den 16.02.2010 16:44, skrev Marcus Denker:
On Feb 16, 2010, at 4:39 PM, Miguel Enrique Cobá Martinez wrote:
El mar, 16-02-2010 a las 14:39 +0100, Luc Fabresse escribió:
Hi,
I think it is related to: http://code.google.com/p/pharo/issues/detail?id=982 If I remember well, there is no primitive with nano second accuracy so it is impossible to have it in real.
Yes, and indeed nano second accuracy is overkill for my current problem. I only want some given precision so that
DateAndTime now < DateAndTime now
is always true, so that can be used to order events (object creation in this case) using the date.
But it's not. DateAndTime now <= DateAndTime now. If you are batching them together so close that resolution is an issue why not rewrite it to something like:
currTime:= DateAndTime now. obj Count:= 0. someLoop whileTrue: [ newObj := aClass new time: currTime+ objCount; yourself. currTime := currTime +1. ]
Thank you very much! I am doing something similar to this.
If this resembles your approach, just remember to make sure that the function is never called frequently. If it is, you'll have to account for (if likely enough to be a potential problem): a) The function being called twice in the same DateAndTime resolution interval (code to handle this which will be different based on whether you want to protect against sequential or concurrent calls) b) You don't allocate so many objects you get an overflow into the next now, then call again. Cheers, Henry
El mar, 16-02-2010 a las 18:56 +0100, Henrik Johansen escribió:
Den 16.02.2010 18:32, skrev Miguel Enrique Cobá Martinez:
El mar, 16-02-2010 a las 18:26 +0100, Henrik Johansen escribió:
Den 16.02.2010 16:44, skrev Marcus Denker:
On Feb 16, 2010, at 4:39 PM, Miguel Enrique Cobá Martinez wrote:
El mar, 16-02-2010 a las 14:39 +0100, Luc Fabresse escribió:
Hi,
I think it is related to: http://code.google.com/p/pharo/issues/detail?id=982 If I remember well, there is no primitive with nano second accuracy so it is impossible to have it in real.
Yes, and indeed nano second accuracy is overkill for my current problem. I only want some given precision so that
DateAndTime now < DateAndTime now
is always true, so that can be used to order events (object creation in this case) using the date.
But it's not. DateAndTime now <= DateAndTime now. If you are batching them together so close that resolution is an issue why not rewrite it to something like:
currTime:= DateAndTime now. obj Count:= 0. someLoop whileTrue: [ newObj := aClass new time: currTime+ objCount; yourself. currTime := currTime +1. ]
Thank you very much! I am doing something similar to this.
If this resembles your approach, just remember to make sure that the function is never called frequently. If it is, you'll have to account for (if likely enough to be a potential problem): a) The function being called twice in the same DateAndTime resolution interval (code to handle this which will be different based on whether you want to protect against sequential or concurrent calls) b) You don't allocate so many objects you get an overflow into the next now, then call again.
Not a problem, I am doing a seldom called (just in development that is) method to generate several thousand objects (each one with several hundred objects inside) for populating my application and test search performance in Magma. Due that in my application each object has a creation date, I wanted to emulate the creation date generated on real usage of the app. But my bulk load machine it appears to be too fast, so several hundred of objects appear to be created at the very same time. Also running my tests and comparing creation date of the object being tested respect to end time of a given operation (that supposedly takes some time in real life), are showing operations taking zero time. So the tests fail. I worked around this by artificially putting a (Delay forSeconds: 1) wait right before testing so that the tests can register operations separated by at least a second and run successfully. Anyway, thanks to everyone for the "knowledge transfer" Cheers
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
There is a microsecond clock in the macintosh vm, obviously this could be extended to give date/time back in microseconds. On 2010-02-16, at 5:39 AM, Luc Fabresse wrote:
Hi,
I think it is related to: http://code.google.com/p/pharo/issues/detail?id=982 If I remember well, there is no primitive with nano second accuracy so it is impossible to have it in real.
Luc
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
participants (10)
-
Brent Pinkney -
csrabak＠bol.com.br -
Henrik Johansen -
John M McIntosh -
Luc Fabresse -
Marcus Denker -
Mariano Martinez Peck -
Miguel Enrique Cobá Martinez -
Schwab,Wilhelm K -
Stéphane Ducasse