Usb Format Problem Fix
Annabella Wasik
As you can see in the file from date 25th till the date 31st the format is dd-mm-yyyy hh:mm:ss but it changes from date 1st to 12th to dd-mm-yyyy hh:mm and from 13th again comes to general format which is dd-mm-yyyy hh:mm:ss
When I run your VI, it runs just fine creating a new spreadsheet with dates in the format of 12/25/12 0:30. I open your excel sheet and it shows a variety of formats with with some being custom at m/d/yy hh:mm, and others being "general".
First question, are you doing european date formats where the date comes before the month? My guess is that you have a mismatch of date formats between how LabVIEW is formatting strings and how Excel is interpreting them. Check all your date format settings in Windows, Excel, and LabVIEW. If you find discrepancies, you may need to be more specific in your date format codes in Excel. Look at the help file for time/date format codes.
I'm wondering why your VI looks so complicated. First, you are using a while loop when it looks like you only need a For Loop, that way you don't need to worry about a while loop stop condition. Second, your array manipulation seems more complicated than necessary. Rather than delete from array and insert into array, you should only need to Replace Array Subset.
Third, and most importantly, the string to time to date cluster, to time, to string to Build Array, all seems unnecessarily complicated. What are you really tyring to do? It seems like there are much easier ways to do it with a fraction of the nodes and wiring.
It is not a formatting issue, in your loop you always add one day keeping the same month and same year. This seems to be creating the issue. Just convert your timestamp to double, add loop index time 86400 (number od seconds in one day) to this value and convert back to timestamp. No need to convert to date record. I agree with Ravens Fan that your code can be simplified a lot.
I have the same problem with the dates from jan 1st to jan 12th. It is Excel autoformatting the dd-mm-YYYY H:M format to mm/dd/yyyy h:mm. (I have a French version of Excel 2010). Up to jan 12 Excel uses one of its pre-defined format and switches day and month and use 12h time.
This autoformatting can be disabled by adding a space in front of the date time string. I can't see how RavensFan implemented his version (I don't have LV2017) but here's my simplified version of your code.
If it's an .xls file, you'll probably need to modify (:repair) the file extension to .xslx. If you run a google-search, you'll easily find some articles that will walk you through the process as well.
Did this post help you? If so please give it a Like below.
Did this post fix your issue/answer your question? If so please press the 'Accept as Best Answer' button to help others find it.
Still stuck? Ask me a question! (Questions asked in the community will likely receive an answer within 4 hours!)
After checking throughally it seems when this is done in Excel 2016, it saves as a CSV format but with a .xlsx file extension. Making Excel think it's corrupted when it's just under the wrong file extension. Seems to be an issue exclusively with using the dropbox saving function in office.
Try renaming to .csv and doing save as outside of Dropbox. Currently dealing with an identical issue and found it was still in it's original format when used the dropbox saving function in office 2016. Making it seem corrupted when it was just something in the process changes the file extension but not the actual format.
I'm seeing the opposite. When I do a Save As, specify Dropbox as the location and select CSV as the file type, it's saving the file in the XLSX format with a .csv file extension. Saving to the Dropbox folder directly, without using the Save to Dropbox functionality, the file is saved correctly.
So it seems it's a problem with the save as function in general in excel not just any particular file format. The function of doing a save as to a different format is not working correctly when saving to dropbox.
Excel deals with dates as serial numbers, beginning with date #1 being January 1, 1900. So you need to get to the unformatted date--or at least to recognize its presence--in order to get Excel to be dealing with the dates you have in mind. Just changing the format isn't dealing with the underlying reality that Excel sees.
Hi,
The date format might be linked to your language preference in Excel. Check the language preference in Options>Language. If the language installed is English (United States), the date format will be American (mm/dd/yyyy). If English (United Kingdom) has been installed, the date format will be English (dd/mm/yyyy). You could install your preferred language. I hope this helps.
I had problems also. I was able to import file to excel and add a column for description which my bank did not show. Also, the date format you have appears might be a problem - mine was 05/01/2018 - but I am in Australia.
In a different app I noticed this:
My data source is a Google sheet.
The dates in the sheet have a format dd-MM-yyyy.
The columns in the new table component have the same format: dd-MM-yyyy.
The date components also have that same format.
Yet I see that a date in the sheet 01-10-2021 is presented in Retool as 10-01-2021, both in the table component and in the Date component.
Is this a bug or am I doing something wrong?
Could someone please take a look at my problem?
I e-mailed it on Sept 6 to the support e-mail address but since Retool changed its support policy I posted this on this forum.
So it's really important to have a solution soon.
Could someone be so kind to help me?
I would highly appreciate it.
It looks like the auto-complete issue is actually a known bug where the local region settings determine the date input format for auto-complete over the format specified in the component settings. I've added your feedback to the internal tracking ticket we have for it and can let you know here when it's fixed.
I tested comparing date strings but that works, so that is not the issue.
The strange thing is that when I browse through my table and go to the record with the problem, the custom validation rule does not result in the invalid message.
However when I click the date component and leave that field without changing anything, the invalid message appears.
When I browse to a different record and then move back to the problem record, the invalid message is there immediately.
I tested it in a very small app with only the two fields and then there is no problem at all.
The question is what is the difference between the real app and the test app.
The only difference I see is that in the real app the date compents have a default value from a table component.
Could the problem be related to the known bug that Kabirdas mentioned?
I did some debugging and think I found a cause for the problem.
When I show dateContractStart.value in the invalid-message (after "?" in the custom validation rule) in most cases it is presented in the format yyyy-MM-dd but sometimes in the format dd-MM-yyyy (the formatted value format). And that's why the rule sometimes does not work.
Therefor I suspect that it has to do with the known bug that Kabirdas mentioned.
Could someone from the Retool team confirm this and let me know when the bug has been fixed?
I would appreciate your response.
The value of date components is stored as strings, so it's important that they be in YYYY-MM-DD format otherwise you'll see something like the following be true '01-01-2023 < 02-01-2020' . Passing your dates through the moment library can help with the conversion but moment won't recognize DD-MM-YYYY automatically as a valid date format so you need to pass that explicitly as well (more on parsing dates with moment here).
@Keirdre have you attempted formatting citations in other documents, just to see if it works? Something else to try would be copy/pasting the contents of the document to a fresh Google Doc and formatting there, as well as downloading to Word format and using our Word plugin to convert and format the citations (then you can re-convert to GDocs).
Also have recently had a problem with SU files taking a long time to load
Have run Thom toms toolbar fix and manually cleared the registry which ftxed
the problem except when I have my laptop connected to a second screen
My Date table is a csv file and it works completely fine in PBI Desktop, but I'm re-creating the same dataset as a Dataflow, but for some reason, the column is given the highlighted error message, which I don't get on the desktop. What am I missing here, please?
Change type by using locale should work, you need to select English (United Kingdom) here as it expects the locale of original data. After changing column type, you will see data in the format which is identical with your account/browser settings. I guess your account/browser settings is using English(United States) so you will get result in that format. That's also why you have this error initially when changing data type.
I @The_Fray I amended your workflow and the DateFormat formula produces an output. Datetimeformat changes the date into a string so the datetime functions won't work and cannot be a Date data type in Alteryx and has to be a string. If you want to use Datetime functions you need to convert your date into YYYY-MM-DD format and as date data type. and then apply the datetime functions. DateTimeFormat function is generally used as last step since the data type has to be a string.
I had similar problems with my Sandisk 64GB micro sdxc when I attempted to mount the card in my Samsung I9300 International version. After formatting the card with my Windows 7 operating system my phone displayed the following message:
e59dfda104