I have a dashboard in Looker Studio that is suddenly showing inaccurate data (it worked fine the day before).
I had added a column to a data source. When I reconnected the data source, I can see that the date format is showing the old date format, YYYYMMDD (I don't recall seeing that before).Previously the date format in this Google Sheet was formatted as Jan 2023 (01/01/2023 in the formula bar). I changed the format to MM/DD/YYYY. There were still inaccuracies in the graphs.
I tried to upgrade from Date Compatibility to Date and the graphs are blank or have an error message, see below.
Date Compatibility/old date format
Empty graph
Failed to get data message
I have one data source that is the old date format.
I upgraded from Date Compatibility (YYYYMMDD) to Date. The format in Google Sheets is MM/DD/YYYY.
The charts went blank or I received an error message "Failed to get data"
I then went into the date fields in the blend and in the chart, removed the old date fields and entered them in again.
The charts are either still empty or have the error message.
Related
My Google Sheets is currently set to UK London GMT
I have some data that is needed in UK format and other data that is needed in US format within the same sheet.
I'm using date time as dd-mm-yyyy hh:mm:ss and have been trying to convert this to US yyyy-mm-dd hh:mm:ss
When formatting the UK date time to as text and using this formula
=ARRAYFORMULA(REGEXREPLACE(A2:A, "(\d{4})-(\d+)-(\d+)", "$3/$2/$1"))
It should be converting for me however is stays the same.
I have also tried simply copying and pasting in a new column with the intention of changing format from within formatting settings but when pasting it seems to randomly select different formats in some rows using / instead of - and in other rows returning a number instead of date time.
How can I get this to work correctly?
try:
=TEXT(A2, "e-m-d h:mm:ss")
I have a Power BI file that connects to a data model via SSAS. The data model origin is a SQL Server view with some computed columns added in via SSAS.
One of the visualisations is a Hierarchical Slicer that shows dates. The field is not one of the computed SSAS columns. It displays in DD/MM/YYYY format but when I place the file on a Power BI Report Server the format is Americanised to MM/DD/YYYY. I want it to be DD/MM/YYYY.
The same field is used to populate a table visualisation but in there it remains DD/MM/YYYY. Just the slicer is affected.
This blog https://community.powerbi.com/t5/Desktop/date-format-in-slicer/td-p/215627 seemed to have the answer I needed but these settings were already applied and still the slicer shows MM/DD/YYYY.
Its not a problem when I open the pbix file locally; there, the slicer shows the dates as DD/MM/YYYY, its just when its on the server. The same problem persists in Test and Production and I have checked those settings and they are as the blog indicates. Other blogs identify this with the slicers but do not present a real solution as its not seen as a problem in those topics.
I've only spent a month working with Power BI so have no real experience to draw upon. I know that SQL Server defaults to American English when connecting to a database and I have changed that to British English but still the same problem. How do I get the slicer showing as DD/MM/YYYY as in my local copy?
Select the Date column and then go to the Modeling tab and change Format to whatever Date format you want.
OR
You can create a calculated column using the FORMAT method in DAX to convert date format as you want.
See reference here: https://msdn.microsoft.com/en-us/library/ee634398.aspx
Power BI is missing the formatting in their recent releases. However, the below solution works for me:
Create a Calculated Column ref. the original Date column and apply "Short Date" format for Date, example:
Transaction Date =
FORMAT(DATE(
YEAR([Transaction_Date]),
MONTH([Transaction_Date]),
DAY([Transaction_Date])
), "Short Date")
I am pulling in date information via MySQL and the date is in the string format of "MM/dd/YY hh:mm:ss"
Using the built in conversion to date isnt working; so I tried using DATEPARSE and also using DATE and manually parsing it. I have had no luck and I have no idea why I keep getting "null" as the answer or it is putting the month as year, day as month, and year as day.
See screenshots below for the different formulas I have used:
DATEPARSE
Original date format
DATE with manual parsing
This worked for me using your example original data
DATEPARSE('mm/dd/yy hh:mm:ss',[Time] )
I used tableau's documentation of custom date formats to find the right formula for the format.
If this doesn't solve the problem then it is most likely due to a Locale issue. The Dateparse function relies on the locale specified by your computer settings to interpret and then display the strings you want to convert and can affect whether a certain format can be specified. This means that if a certain format is not recognised it will return a null. This will often occur is the windows region and language format is changed to another language other than the original language the workbook was created it.
So check your locale and if required execute the following workaround (documented by tableau here):
Open Windows control panel > region and language > format
Click format dropdown and change to original language of workbook creation
click ok or apply and reopen tableau work book
I've been tasked with getting data from an existing database table and transferring it into another. Everything is fine except the date in the original table is in a format that I don't recognise. It looks suspiciously like a unix timestamp but when converting it it seems to be coming out as the year 2727 or something.
Here is an example of what's in the existing table: 1424786878240
The matching date for this on the front end of the site is 24th February 2015. I cannot seem to find any correlation between this and the number in the database - and since I have no access to the original site code I am unable to determine how it's being converted.
If anyone recognises this date format / structure I would appreciate some help.
I uploaded and parsed through an excel sheet using cfspreadsheet and inserted all the values into database and the problem is that [my excel sheet has a date range from 1/2/2016 to 29/02/2016,from 1/2/16 to 12/2/2016 it is right aligned in excelsheet and remaining is left aligned...]. The value is being inserted into the db but I cannot able to fetch the values from 1-12 using where condition in db. I tried manually changing the date format in my excel sheet..what happened is
..02 January 2016
02 February 2016
.
.
02 December 2016
13/02/2016
14/02/2016
.
.
up to 02/12/2016[mm/dd/yy] it is displaying dd as month notation and from 13/02/2016[dd/mm/yyy] it is displaying properly, I tried with all formatting options, and I need to implement it in code. I think while downloading the data itself the date is not getting formatted properly, I tried with different excel sheet but of no use...and I tried converting these dates into specific format using coldfusion code and but it doesn't works for me..
<cfset sheet = spreadSheetRead("D:\file123\final1231.xls")>
<cfset SpreadSheetFormatColumn(sheet,{dataFormat="yyyy-mm-dd"},3)>
<cfset SpreadSheetWrite(sheet,"D:\file123\final1232",true)>
can any one help me in this?
What looks to me is that locale is set to 'English (United States)' in your excel and that is why for first 12 rows your excel is treating values as valid date but starting 13th row the data is invalid and hence excel is treating it as string (hence left aligned). Try manually changing excel locale to 'English (India)' or similar and you will see data aligned properly.
Also Cold Fusion internal date-time format is American (mm/dd/yyyy) and by default will interpret date and time into American format. I think while inserting data you can create date with something like below to make sure what data gets inserted:
#createDate(listLast(dt,"/"),listFirst(listRest(dt,"/"),"/"),listFirst(dt,"/"))#
Here dt is the data column that you want to insert. You may need to put some checks, based on the data, to avoid any run time errors.