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