How to verify that a value is a valid date in livecode - livecode

I am after a code to check the content of a field in livecode and determine if this value is a date or time value.

Beyond what Mark implied, the fact that "123456" being a date might break the intent of your handler, and what you already know, that there are several date formats, you may also want to validate the user input at a lower level.
What I mean is that if I were writing a validation routine, I would NOT permit "123456", considering this a data entry error. So you will probably want to test the format of the string itself, making sure it "appears" to be a valid date, as well as actually being a valid date.

If you want to use the local date format, you need to set the useSystemDate to true.
set the useSystemDate to true
put "123456" into myDate
put (myDate is a date and myDate is not an integer)
put ("12/12/15" is a date and myDate is not an integer)
However, sometimes this may not be what you want. If you provide more specifics, I might be able to come up with a better solution.

Related

use dayjs to parse a date without a year

I would like to use day.js to parse a date string that does not include a year. In Node.js (and Chrome, I am told), it successfully parses the string as a date but sets the year to 2001.
dayjs('06-05'); // 2001-06-06T07:00:00.000Z
dayjs('6/5'); // 2001-06-05T07:00:00.000Z
dayjs('5 June'); // 2001-06-05T07:00:00.000Z
Is there some way to detect that the original input string does not contain a year? I have considered:
assuming that "2001" means "no year entered" -- since my use case doesn't need the year 2001, that would be fine, but I don't want to count on that date parser always pointing to 2001.
manually splitting the date string. This is also problematic, since there are many delimiters and languages to consider.
Many thanks.

How to standardize the text function in Excel?

=text(5/7/19,[Windows date format]) depends on the computer you are opening the Excel file from. For instance: =text(5/7/19, "mm/dd/yy") works on the company computer because that's how the windows formatted the date, but in my computer, it has to be =text(5/7/19, "dd/mm/yy") else it will return a different value and using other functions such as =datevalue(text(5/7/19, "mm/dd/yy") will return a #VALUE! error on my home computer. This is not good because it is very variable when the file is being moved around computers. How to standardize this?
So what about:
=TEXT(43592,"mm")&"/"&TEXT(43592,"dd")&"/"&TEXT(43592,"yy")
Or reference a cell where you have put your date.
Unfortunately I don't think it is possible - see the this link
Quote:
Problem: The value in the date_text argument is not in sync with the system’s date and time settings*
If your system date and time settings follow the mm/dd/yyyy format,
then a formula such as =DATEVALUE(“22/6/2000”) will result in a #VALUE! error. But the same formula will display the correct value when the system's date and time is set to dd/mm/yyyy format.
Solution: Make sure that your system’s date and time settings (both Short time and Long time) matches the date format in the
date_text argument.
I think the only solution is to make sure that your date is in the valid (i.e. recognised by the system) date format before any other function (like DATEVALUE) is applied.
It will be easy to achieve if your function is simply =text(5/7/19,[Windows date format]). You can reference your cell field (e.g. =[#Date]) and format a given cell using an "universal" date format (the ones that start with * sign).
However, if you are combining =text(5/7/19,[Windows date format]) with some other formula (e.g. when you want to display a full sentence like A very important event happened on 5/7/19) then, unfortunately, cell format won't save you here and we're out of solutions. In such case the end user would need to manually modify the date cell in order to make it recognisable.

Can't convert Date to Number

I have a userform and I take start and end dates from user as in dd.mm.yyyy format. To make it easier to compare dates, I want to turn it to a double or long type of value. I have tried as in below but it gives me an error of type mismatch.
endDate is already defined as Double and as you can see, Me.g_end.Value is string in proper format. Why do I get this error, and how can I handle it?
Also I need to add, DateValue(Me.g_end.Value) works fine with my friend to get value of date who uses Excel 2013. I use Excel 2016.
You need to enter dates in a valid format in order for Excel to recognize them as dates.
As far as I know, nowhere uses dots (periods) in dates. (As I recall, nowadays only one country in the world even recognizes dots as am official date separator.)
Click your Start menu and type Region to find and open Windows Region and Language Settings.
Note the format that your system is expecting for Short Date, including the symbol between each date part, and try entering your dates in Excel like that.

Using POI to find out format for a cell

What is the correct way to get the CellFormatType for a cell (DATE, NUMBER, TEXT, GENERAL) ?
cell.getCellStyle.getDataFormat() returns a Short value, which does not map to the above constants.
I cannot just use cell.getCellType for the following reason. For certain rows, there may be a string prefix like <> or > in front of the value. In that case, getCellType will return CELL_TYPE_STRING. So the only way to get the underlying type appears to be to look at the format for the column.
Thanks
I don't know a direct route from Cell to CellFormatType, but there are various ways to determine particular types:
General? getDataFormat will be 0 (or more reliably, getDataFormatString will be "General")
Date? Check out DateUtil.isCellDateFormatted
Text? Typically you'd check for Cell.getCellType = CELL_TYPE_STRING, but since you say you can't do this (see comments below), you could also try checking if getDataFormatString is "#" or "text" (both are possibilities for plain text)
Number? Again, usually you'd just check for CELL_TYPE_NUMERIC. Note that dates are also considered numbers, so check for dates first.
(If the cell type is CELL_TYPE_FORMULA you should check getCachedFormulaResultType instead)
I cannot just use cell.getCellType for the following reason. For certain rows, there may be a string prefix like <> or > in front of the value
I'm not familiar with this problem. Perhaps you have a custom format which prepends characters before the number? My notes on text detection above might help you in this case, but I suggest you double-check that your spreadsheet actually has the relevant information (i.e. it isn't just Excel being clever when you re-open the sheet): log the cell type, format and format string, and confirm that there actually is a difference on the relevant cells. It's possible that your cell is actually being saved as text, with no distinguishing mark. In this case, you'll need to add some special heuristics for your specific scenario.
Finally, since you seem confused about the returned value from CellStyle.getDataFormat; it's just an index in a sheet-wide index → format-string table. You can (and I'd say usually should) use getDataFormatString to get the string format directly. The standard cell formats are listed in BuiltinFormats, which you can use as a reference to see which format strings you might find (but always check the format string, not the ID, otherwise you'll fail to detect custom formats correctly).

CDate to recognise Australian date format?

I have a spreadsheet I created mid-August which has a table with one column for every day since then. The column header is the day's date. The date is displayed how I want it to be displayed: "dd/mm/yyyy"
However, I have macro which needs to read these dates in order to perform its work. Because I am using a table, the dates seem to be held as text rather than as 5-digit numbers (when I set the header cells' format to "General", it remains with the "dd/mm/yyyy" format rather than changing to a 5-digit number. This wasn't a problem until the 1st of September, after which CDate (in the macro) began reading these dates as "mm/dd/yyyy"
Is there any way to make CDate recognise the Australian date format rather than the American? Or failing that, make the table headers stay as dates rather than as text? I'd rather avoid having to convert the Table back to a range, as the macro is designed to use table attributes, ListColumns etc.
UPDATE:
I've narrowed down the problem. It isn't the date, but the ListColumn.Name property. For some reason it is re-converting my date. I'm using Format() to set the date format, like so:
CreateHistoryColumn.Name = Format(headerDate, "dd/mm/yyyy")
MsgBox Day(headerDate) & "/" & Month(headerDate) & "/" & Year(headerDate)
MsgBox Format(headerDate, "dd/mm/yyyy")
MsgBox CreateHistoryColumn.Name
Where CreateHistoryCol is an object of class ListColumn. The 3 MsgBox calls display the following:
6/9/2012
06/09/2012
9/06/2012
So the Format() call formats the date correctly, but the call to ListColumn.Name serves to alter the format to "mm/dd/yyyy".
From help file:
CDate recognizes date formats according to the locale setting of your system. The correct order of day, month, and year may not be determined if it is provided in a format other than one of the recognized date settings.
I hate relying on the locale because most of the time it seems to do the opposite of what I intended, plus it makes code less portable.
I usually deal with dates as explicitly as possible:
Split your string into the various parts (year, month, day, as well as hour, minute, second if relevant)
Stick the various parts in the DateSerial function. This returns a Date type. (To that you can add the output of TimeSerial, if applicable.)
If necessary for display purposes, format this Date as appropriate using the Format function, which returns a string.
Here's a worked example.
As I showed in the update, the ListColumn.Name method was responsible for the unwanted conversion. I still don't know why, but there is any easy fix:
CreateHistoryColumn.Name = CLng(headerDate)
This forces the header to be treated as a number, and therefore it can be recognised as its proper date. I can't explain it any further than that.

Resources