Converting string date to Human Readable Format HRF (Stata) - date

version: stata15
Date (format %9s), type 8s - 20171230
date
20171230
20171230
I want to be able to see 30dec2017,
gen newdate = date(date, "YMD")
format newdate %td
list
here is what I see
date newdate
20171230 .
Why do I see a missing data in the new date variable? what am I doing wrong in the newdate %td command ?

ANSWER TO ORIGINAL QUESTION:
This makes no obvious sense to me. Questions like this waste your time as well.
You don't give a clear reproducible example of your data. In a recent version of Stata, help dataex tells you how to do that. If you're using an older version of Stata then you should be telling us that.
Your first sentence seems to be telling us that you have a string variable date with storage type str8 and display format %9s.
If that is so, then tostring is pointless, as you already have a string variable.
The statement gen date = date(date, "YMD") is illegal, as date already exists as a variable. If you typed that, it will not have worked. If you typed something else, you should tell us.
The format %td should give you a fairly readable date. So, you've already answered your own question. If you have a numeric date variable, read help datetime display formats to learn more.
EDIT The fact that most of the above is irrelevant to the real question shows how you wasted time not asking the real question.
ANSWER TO MODIFIED QUESTION:
I can't reproduce your problem. You report a missing date result, and clearly no kind of display format will make sense of that. But Stata 15.1 does this for me. So, something is wrong with what you are telling us. Perhaps your Stata is corrupted, or something else is not as you say.
clear
set obs 1
gen str8 date = "20171230"
gen newdate = daily(date, "YMD")
list
+--------------------+
| date newdate |
|--------------------|
1. | 20171230 21183 |
+--------------------+
21183 will show nicely with a %td format. Using daily() rather than date() is irrelevant, as the same result is yielded by date().

Related

In Google Sheets, subtract string "YYYY-MM-DD HH:MM:SS ET" from =now(). How to convert string to number?

We have the string 2022-06-01 11:01:05 ET in Google Sheets and we are looking to compute the difference between this string and =now(). We cannot simply subtract the cells because we cannot subtract a string from a number/date. How can we subtract and get the difference between timestamps (not just dates, precision to the hh:mm:ss would be useful.). The output we are looking for is a simple decimal number representing the time difference, that we can convert into minutes or seconds as needed.
try:
=(NOW()*1)-(1*REGEXEXTRACT(A1, "(.*) "))
then:
=TEXT((NOW()*1)-(1*REGEXEXTRACT(A1, "(.*) ")), "[h]:mm:ss")
See my comment to your original post. But as your post is written, you need to do this for only one cell. So assuming that cell is A2:
=NOW()-REGEXEXTRACT(A2,"(.+)\s\S+$")
... then set the format of that output to Duration.
Understand that since the NOW function is volatile (constantly changing), the output will also constantly be changing. Hopefully, that is what you want and expect.
You mention:
We have the string 2022-06-01 11:01:05 ET in Google Sheets...
It is safer to use:
=NOW()-REGEXEXTRACT(B1, "(.*) ")+(x/24)
(where x=difference in time zones and B1 is the cell containing the sting)
As an example, if your sheet's time zone is "(GMT+00:00) London", x should be adjusted accordingly
WHY?
Both of the answers provided by Erik as well as player0 will work if and only IF you are in the same time zone.
Considering the fact though that you do mention that the time zone in your question is a string (meaning fixed) as well as it is quite common for a Google Sheet to be in a different time zone, it is safer to use the above formula.
Please have a look at these times

Struggling with dates formats, want YYYY-MM-DD

As an absolute beginner to SAS I quickly ran into problems with date formatting.
I have a dataset containing transaction with three types of dates: BUSDATE, SPOTDATE, MATURITY. Each transaction is represented on two lines, and I want BUSDATE and SPOTDATE from line 1 but MATURITY from line 2.
In the original set, the dates are in YYYY-MM-DD format.
DATA masterdata;
SET sourcedata(rename(BUSDATE=BUSDATE2 SPOTDATE=SPOTDATE2 MATURITY=MATURITY2));
BUSDATE=BUSDATE2;
SPOTDATE=SPOTDATE2;
IF TRANS_TYPE='Swap' THEN;
MATURITY=SPOTDATE;
RUN;
Problem is, this returns something like 17169 (which I guess is the number of days from a certain date).
How can I make it output in YYYY-MM-DD format - or is this approach wrong; should I first convert the date variables to some SAS date format?
if you have valid SAS dates, just add a FORMAT statement to your DATA STEP.
Format busdate spotdate maturity yymmdd10. ;
SAS dates are numeric variables. They represent the number of days since 1/1/1960. You use a FORMAT to display dates.
Adding to CarolinaJay's answer, you normally want to keep them as numeric format, since you can do math (like "# of days since date X") with them. However, if for some reason you need a character variable, you can do this:
date_As_char=put(datevar,YYMMDD10.);
Incidentally, YYMMDD10 will actually give you YYYY-MM-DD, as you asked for; if you want a different separator, see http://support.sas.com/documentation/cdl/en/lrdict/64316/HTML/default/viewer.htm#a000589916.htm (YYMMDDxw. format) - if you put a letter after the last D, for certain letters, you get a different separator. Like, YYMMDDn10. gives you no separator, or YYMMDDs10. gives you slashes. YYMMDDd10. gives you dashes, just like omitting the letter would. This concept also applies to MMDDYY formats, and I think a few others.

MakeInstant from Text doesn't work - Argument to MakeInstant should have a different form

I've been playing with MIT AppInventor and attempted to calculate a duration between two dates.
I take date values from two text fields. Clock.MakeInstant says it's only able to accept dates in MM/DD/YYYY format so I was careful to do that. Still, when I attempt to feed them into MakeInstant it always pops the same message about being able to only accept MM/DD/YYYY hh:mm:ss or MM/DD/YYYY or hh:mm. I printed entered text values before passing them to MakeInstant to confirm that they are not somehow corrupted and they are fine -- each just a date in MM/DD/YYYY format.
I have no idea what else to try. As far as I can tell I followed the instructions to the letter. Any examples on how to pass a date as text to Clock.MakeInstant?
see this screenshot source: https://groups.google.com/d/topic/app-inventor-shared-utilities-repository/3bA4wczU9pU/discussion
Taifun

Bug in Zend_Date (back in time)

I have a very strange problem, Zend_Date is converting my timestamp to a year earlier.
In my action:
// Timestamp
$intTime = 1293922800;
// Zend_Date object
$objZendDate = new Zend_Date($intTime);
// Get date
echo date('Y-m-d',$intTime).'<br>';
echo $objZendDate->get('YYYY-MM-dd');
This outputs:
2011-01-02
2010-01-02
Can anyone tell me what i'm doing wrong?
From the ZF issue tracker it seems this is a known issue:
Recently a lot of ZF users are filing a bug that Zend_Date returns the wrong year, 2009 instead of 2008. This is however expected behaviour, and NOT A BUG!
From the FAQ:
When using own formats in your code you could come to a situation where you get for example 29.12.2009, but you expected to get 29.12.2008.
There is one year difference: 2009 instead of 2008. You should use the lower cased year constant. See this example:
$date->toString('dd.MM.yyyy');
instead of
$date->toString('dd.MM.YYYY');
From the manual
Note that the default ISO format differs from PHP's format which can be irritating if you have not used in previous. Especially the format specifiers for Year and Minute are often not used in the intended way.
For year there are two specifiers available which are often mistaken. The Y specifier for the ISO year and the y specifier for the real year. The difference is small but significant. Y calculates the ISO year, which is often used for calendar formats. See for example the 31. December 2007. The real year is 2007, but it is the first day of the first week in the week 1 of the year 2008. So, if you are using 'dd.MM.yyyy' you will get '31.December.2007' but if you use 'dd.MM.YYYY' you will get '31.December.2008'. As you see this is no bug but a expected behaviour depending on the used specifiers.
For minute the difference is not so big. ISO uses the specifier m for the minute, unlike PHP which uses i. So if you are getting no minute in your format check if you have used the right specifier.
To add to zwip's answer, what happens behind the scenes is that your date format YYYY-MM-dd is actually translated into o\-m\-d, which is then passed to PHP's date() function internally with the timestamp you provided.
Like mentioned in the other answer, and in the documentation for the o format on the date format page, the calculation of the year based on the ISO week can sometimes result in the year being one different to the value that you expect.

Secure way to figure out if a given date format has an 12h or 24h format?

I know this sucks. Date stuff sucks hard. But: Imagine a date format like "dd-MM-yyyy h:mm" how would you tell for sure what time mode that is? AM / PM or 24 hour? I'd say: If there is no "a" in the date format, then that's no AM / PM stuff and therefore it's nice 24h stuff. What do you think?
If you are given a date, such as 11:15, you can't know whether it is AM or PM. Just as you don't know whether when I say Deer, I mean one or more than one. As a program designer, you have to remove ambiguities or make assumptions. You could either force the data to have AM/PM, or tell the provider of the time to give it to you in 24 hour format, or you can assume that they are smart enough to realize that without AM/PM you have no way of knowing. Not knowing your situation, I can't tell you how to proceed, but there are issues that transcend plain old programming. Like whether 1,000,000,000 is a billion or a milliard or a trillion or whether a ton is 1000 kilograms or ....
You should rather check for a M or m and not an a.
But "dd-MM-yyyy hh:mm" is surely an ambiguous format.
That is, parsing a date that just looks like dd-MM-yyyy hh:mm can't tell you about the 12/24 format.
You could assume it's 24h format, otherwise something is missing or it would look like "dd-MM-yyyy hh:mm X", where X is 'AM' or 'PM'.
The only truly unambiguous format is ISO 8601 'yyyy-MM-dd hh:mm' with 24h times.