On Thu, May 15, 2014 at 04:02:20PM +0200, Philippe Bruhat (BooK) wrote:
> 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?
Good question. I was thinking it would be at the time generate_new_name
was called but I could argue it either way.
[...pondering...] now I'm thinking we should use the time new() was
called, but provide a method to change that:
$np->timestamp_epoch( time() );
It doesn't seem worth adding the ability to pass a timestamp to
generate_new_name().
Tim.
