refine {time} substitute

[Adam Reviczky]

Currently the {time} substitute produces a yyyymmddhhmm format (like: 201106190815).

It would be nice if one could define a custom format, like for example the following:
{time} => 201106190815
{time:yyyymmdd} => 20110619
{time:yyyy.mm.dd} => 2011.06.19
{time:yy.mm.dd} => 11.06.19
{time:dd.mm.yy} => 19.06.11

The ones that I would need myself are: yyyymmdd (aka no hours and minutes) and yyyy.mm.dd (separated with dots, no hours and minutes).
Any solution that would produce this is fine with me.

[James Westby (james-w)]

On Sun, 19 Jun 2011 09:50:56 -0000, Adam Reviczky <email address hidden> wrote:
> Public bug reported:
>
> Currently the {time} substitute produces a yyyymmddhhmm format (like:
> 201106190815).
>
> It would be nice if one could define a custom format, like for example the following:
> {time} => 201106190815
> {time:yyyymmdd} => 20110619
> {time:yyyy.mm.dd} => 2011.06.19
> {time:yy.mm.dd} => 11.06.19
> {time:dd.mm.yy} => 19.06.11
>
> The ones that I would need myself are: yyyymmdd (aka no hours and
> minutes)

Does {date} do what you need here?

> and yyyy.mm.dd (separated with dots, no hours and minutes).

Why do you need the form with the dots?

Thanks,

James

[Adam Reviczky (reviczky)]

> Does {date} do what you need here?

Thanks, yes that will do it.

> Why do you need the form with the dots?

I need it, because it is used as a version string (for a daily build).

see:
# bzr-builder format 0.3 deb-version 2011.06.20
lp:~reviczky/context-beta/cont-tmf
nest-part packaging lp:context-beta debian debian

I'm increasing it manually at the moment.

[James Westby (james-w)]

On Mon, 20 Jun 2011 16:18:09 -0000, Adam Reviczky <email address hidden> wrote:
> > Does {date} do what you need here?
>
> Thanks, yes that will do it.
>
> > Why do you need the form with the dots?
>
> I need it, because it is used as a version string (for a daily build).
>
> see:
> # bzr-builder format 0.3 deb-version 2011.06.20
> lp:~reviczky/context-beta/cont-tmf
> nest-part packaging lp:context-beta debian debian
>
> I'm increasing it manually at the moment.

Hmm, I can see why the dots make a difference there, but I'm struggling
to come up with a case where it would make a useful distinction.

I'm not against having this, but I'm unsure if it should allow a full
format string. At the same time I don't really want {date-with-dots}.

I think that the format string is more palatable of the two.

I wonder if something like {date:with-dots} would be a good compromise.

Thanks,

James

[Jelmer Vernooij (jelmer)]

Why do the dots make a difference if leading zeroes are being used? I don't really see the difference of 2011.06.20 versus 20110620

[Adam Reviczky (reviczky)]

The ubuntu version of context has already the dotted versioning, see:
http://packages.ubuntu.com/search?keywords=context

The not dotted version would break the upgrade.