Bug in axis label formatting?

[Ali Atia]

I want to label my x-axis (year) in the following format: %ty'YY.

One approach is to generate a variable and directly set its format:

clear
set obs 10
gen year = _n+2000
format year %ty'YY
list

     +------+
     | year |
     |------|
  1. |  '01 |
  2. |  '02 |
  3. |  '03 |
  4. |  '04 |
  5. |  '05 |
     |------|
  6. |  '06 |
  7. |  '07 |
  8. |  '08 |
  9. |  '09 |
 10. |  '10 |
     +------+

When I generate a graph using the variable, this happens:

gen y = runiform()
twoway line y year

In case it's unclear or unreadable, the x-axis label reads YY 2002' (for instance) instead of '02.

Another approach is to set the format within the graph command, using the option xlabel(,format(%ty'YY)). This produces an identical graph to the one pictured and described above.

Am I doing something wrong, or is this a bug?

[Leonardo Guizzetti]

I wouldn't consider what you've found to be considered a bug as a single quote in a datetime format does not appear to be a supported non-formatting character.

One way to do this is to use -mylabels- by Nick Cox (from Stata Journal). A small bug (?) exposed there has to do with how the quotes are parses by Stata, such that a single space is prevents undesired quote parsing.

local lquote = char(39)
mylabels 2000(2)2010, local(myxlab) format(%tyYY) prefix(" `lquote'")   // or just prefix(" '")
twoway line y year , xlab(`myxlab')

[Ali Atia]

This is helpful, thanks. Still, I wonder why %ty'YY doesn't work in the axis label but works fine when used with display or to format a variable:

. di %ty'YY 2002
'02

[Clyde Schechter]

I can't really answer the question posed in #3 as I don't know how Stata goes about parsing date formats and applying them in either context. But I want to just make a general remark about programming that's somewhat relevant.

It is considered good programming style to reuse the same code to carry out the same function at all places in a program. That assures consistency in the way things are handled. It is a principle I try to follow when I write code. At one time, I was highly critical of code that breached this guideline. But I have learned that when a program evolves and grows over time, with new functionality being added, sometimes the new functionality is, in other respects, best designed in ways that make it difficult or impossible to access the pre-existing code for some functions. It may exist in some subsection of the code that is hidden from where the new functionality lies and, perhaps, can only be made visible in ways that damage the architecture of the program as a whole or render the new functionality inefficient. Or perhaps the desired change needs to blend that functionality with additional functionality that does not mesh well with the earlier approach.

I'm thinking of a program that I have been evolving for over 20 years now (not in Stata), and each new feature becomes harder to integrate cleanly with the earlier code. Design decisions made long before today's new features were imagined constrain what is possible. The real implication is that I should probably rewrite the entire thing from scratch with a new architecture and rethink everything to make it better. Indeed, in principle, I probably should do that. But I do not have the time for that undertaking with the press of my other responsibilities. I suspect that Stata, which has been evolving for a long time, is in a similar position. Perhaps not--perhaps they have the resources to periodically re-build from the beginning, although even so, I can imagine that the need to preserve the performance of users' old Stata code written for earlier versions may also confine them. So it does not surprise me to find that what ,to the user ,is the same thing works differently in different contexts.

[Bjarte Aagnes]

a single quote in a datetime format does not appear to be a supported non-formatting character.

1. The format code below does not fail - which I would expect if apostrophe was illegal. So, -tw- should accept the format

format year %ty!'YY

2. The characters allowed in -format- using "!c" seems restricted to a subset of UTF-8, and I cannot see any documentation of this restriction.

[Derek Wagner (StataCorp)]

Leonardo Guizzetti is right in that the right quote in datetime -format- is
invalid. The list of allowed characters is documented in
-help datetime_display_formats-.

 format year %ty'YY

should return an error. We will look into changing the behavior of -format-.

However, as Bjarte Aagnes pointed out,

format year %ty!'YY

should work. This is a bug caused by the right quote causing a macro in
the graphics code to be terminated early. We will look into fixing this
in a future update.