On Thu, May 15, 2014 at 02:07:23PM +0100, Tim Bunce wrote:
> On Thu, May 15, 2014 at 01:34:21AM +0200, Philippe Bruhat (BooK) wrote:
> > On Tue, May 13, 2014 at 11:11:10PM +0100, Tim Bunce wrote:
> > >
> > > Parse a generated shortname:
> > >
> > > $hash = $np->parse_generated_name($name); # eg to get date etc
> > >
> > > %$hash would contain something like
> > >
> > > {
> > > version => 1, # version of the Basic format
> > > timestamp_string => '140513',
> > > timestamp_epoch => 1400017536,
> > > name => 'foo'
> > > }
> >
> > It should also return 'prefix', and actually all attributes needed to
> > re-create the DSNP instance. So doing something like:
> >
> > $np2 = Data::ShortNameProvider->new( %$hash );
> >
> > would ignore unexpected parameters (timestamp_* and name), and return
> > a Data::ShortNameProvider object equivalent to the original one.
>
> Interesting. Actually timestamp_epoch could be used to provide the
> time value that should be formatted into the short name.
>
I'm not sure I understand this correctly.
If a long-running program creates a Data::ShortNameProvider $np and
uses $np->generate_new_name( ... ) to create short names, is the timestamp
in the name generated each time according to the current value of time(),
or is it fixed to the time() when new() was called?
In the second case, the timestamp_string would be basically fixed.
In my example, I was assuming the first case, and therefore that
timestamp_epoch was the best approximate value we could produce given
a name and a provider.
--
Philippe Bruhat (BooK)
Putting beauty before brains is the surest way to wind up with neither.
(Moral from Groo The Wanderer #24 (Epic))
