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
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
