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