Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • convert string yyyy-mm-dd hh:mm:ss to %td format

    Hello,

    As the title of this question suggests, I have a set of data with variable "Qtm" in string format, e.g., 2010-01-07 19:16:33, I would like to convert it to 07jan2010 format, and ignore the detailed hours in the day. How can I do this? Thanks a lot for any kind help.

    Some data here:
    Code:
    * Example generated by -dataex-. To install: ssc install dataex
    clear
    input str19 Qtm
    "2010-01-07 19:16:33"
    "2010-01-13 15:25:27"
    "2010-03-02 15:29:59"
    "2010-03-15 11:30:11"
    "2010-05-08 11:12:47"
    "2010-06-01 03:23:08"
    "2010-06-02 13:56:21"
    "2010-06-12 12:48:23"
    "2010-06-29 12:49:02"
    "2010-08-11 11:14:59"
    "2010-09-01 08:58:56"
    "2010-09-16 14:34:23"
    "2010-11-16 16:17:54"
    "2010-01-05 09:04:30"
    "2010-01-05 14:08:51"
    "2010-01-16 21:34:55"
    "2010-02-02 15:32:56"
    "2010-03-03 17:54:07"
    "2010-03-04 15:24:07"
    "2010-03-04 16:08:45"
    end

  • #2
    Code:
    g wanted= date(substr(Qtm, 1, 10), "YMD")
    format wanted %td

    Comment


    • #3
      Thanks Andrew for your quick reply!

      Comment


      • #4
        The output of help datetime tells us the # character can be used in mask as a "placeholder for something to be ignored".

        Code:
        . generate wanted = date(Qtm,"YMD#")
        
        . format wanted %td 
        
        . list, clean noobs
        
                            Qtm      wanted  
            2010-01-07 19:16:33   07jan2010  
            2010-01-13 15:25:27   13jan2010  
            2010-03-02 15:29:59   02mar2010  
            2010-03-15 11:30:11   15mar2010  
            2010-05-08 11:12:47   08may2010  
            2010-06-01 03:23:08   01jun2010  
            2010-06-02 13:56:21   02jun2010  
            2010-06-12 12:48:23   12jun2010  
            2010-06-29 12:49:02   29jun2010  
            2010-08-11 11:14:59   11aug2010  
            2010-09-01 08:58:56   01sep2010  
            2010-09-16 14:34:23   16sep2010  
            2010-11-16 16:17:54   16nov2010  
            2010-01-05 09:04:30   05jan2010  
            2010-01-05 14:08:51   05jan2010  
            2010-01-16 21:34:55   16jan2010  
            2010-02-02 15:32:56   02feb2010  
            2010-03-03 17:54:07   03mar2010  
            2010-03-04 15:24:07   04mar2010  
            2010-03-04 16:08:45   04mar2010  
        
        .

        Comment


        • #5
          I have a small campaign with very low success so far to get (experienced) people to set good examples by using daily() not date().

          Why should anyone care? There are reasons not to care, which explains my low success rate.

          N1. date() is the historic name, going back to a time when daily dates were the first date type to get specific support. Integers for years such as 1985 and 2022 worked, and continue to work, just fine most of the time. (Perhaps less than 1% (less than 0.1%?) of Stata users are geologists, archaeologists, ancient historians or literary scholars who need to handle dates that are not AD or CE, and even there negative integers or reversed scales satisfy almost all needs. I have not seen anyone caught out by the jump from 1 BC (BCE) to 1 AD (CE) with no zero in between.)

          N2. date() and daily() give the same result.

          N3. In ordinary language, what is the date? is I think likely to default to the daily date. If asked myself What is the date? I will glance at whatever is convenient and say "29 November", or whatever, the year being usually understood.

          There are reasons to care:

          C1. date() is quite often misunderstood as a generic date function that is ultra-smart and does what the user intends. It takes reading of the documentation to know what date("Nov2022", "MY") does precisely, for example. (Answer: it does not yield a monthly date.)

          C2. Now that there are also functions like
          monthly(), daily() is more easily learned as the function you need as a member of a family.

          C3. It is to be hoped that almost no-one would be misled by emphasis on
          daily() rather than date().

          StataCorp could do more to help. As a user, I recommend

          SC1. The company documents
          daily() as the recommended function name, and mentions date() as the historic equivalent which continues to work.

          SC2. Depending on the success of SC1,
          date() could go undocumented a few releases down the line.

          By the way, we have had Stata's idiosyncratic definition of weeks since 1995, which is a long time to wait for official support of alternatives, such as

          W1. Weeks start on day # of the week or end on day # of the week.

          W2. Epiweeks.

          W3. ISO weeks.

          Comment

          Working...
          X