File/program/lib/dialoglib.php

Description

/program/lib/dialoglib.php - useful functions for manipulating dialogs

This file provides various utility routines for creating and validating user dialogs.

A dialog is a collection of input elements grouped together in a form. An input element (or field) has at least a type (e.g. F_ALPHANUMERIC or F_DATETIME) and a name (e.g. 'title' or 'expiry') and optionally one or more of the other possible properties. The name of an input element uniquely identifies the field in the dialog; it can be used to retrieve the data entered by the user from the global $_POST array.

Note that it is also possible to choose a field name ending in '[]'. This eventually yields an array within the $_POST array. This is used in the multiple file upload feature.

A dialog can be defined via a 0-based or associative array, where every array element is separate input element. Each of the input elements is in itself an associative array with property-value-pairs. The recognition of a property depends on the type, e.g. the number of decimals is irrelevant for a string-type input element.

Here is an overview of properties and field types to which they apply. An 'x' means required, an 'o' means optional and a '-' means don't care.

                type
                | name
                | | value
                | | | rows
                | | | | columns
                | | | | |   minlength
                | | | | |   | maxlength
                | | | | |   | | decimals
                | | | | |   | | | minvalue
                | | | | |   | | | | maxvalue
                | | | | |   | | | | |   options
                | | | | |   | | | | |   | label
                | | | | |   | | | | |   | | accesskey
                | | | | |   | | | | |   | | | alt
                | | | | |   | | | | |   | | | | class
                | | | | |   | | | | |   | | | | |   multiple
                | | | | |   | | | | |   | | | | |   | viewonly
                | | | | |   | | | | |   | | | | |   | | tabindex
                | | | | |   | | | | |   | | | | |   | | | title
                | | | | |   | | | | |   | | | | |   | | | | hidden
                | | | | |   | | | | |   | | | | |   | | | | |   autocomplete [1]
                | | | | |   | | | | |   | | | | |   | | | | |   | id
                | | | | |   | | | | |   | | | | |   | | | | |   | |
F_ALPHANUMERIC  x x o o o   o o - - -   - o o o o   - o o o o   o o
F_INTEGER       x x o - o   o o - o o   - o o o o   - o o o o   o o
F_REAL          x x o - o   o o o o o   - o o o o   - o o o o   o o
F_DATE          x x o - o   o o - o o   - o o o o   - o o o o   o o
F_TIME          x x o - o   o o - o o   - o o o o   - o o o o   o o
F_DATETIME      x x o - o   o o - o o   - o o o o   - o o o o   o o
F_PASSWORD      x x o - o   o o - - -   - o o o o   - o o o o   o o
F_CHECKBOX      x x o - -   - - - - -   x o o o o   - o o o o   - o
F_LISTBOX       x x o o -   - - - - -   x o o o o   - o o o o   - o
F_RADIO         x x o - -   - - - - -   x o o o o   - o o o o   - o
F_FILE          x x o - o   - - - - -   - o o o o   o o o o -   - o
F_SUBMIT        x x x - -   - - - - -   - - o o o   - o o o -   - o
F_RICHTEXT      x x o o o   o o - - -   - o o o o   - o o o o   - o
F_CSRFTOKEN     x x x - -   - - - - -   - - - - -   - - - - x   - -

There are two more properties: 'errors' and 'error_messages'. These properties can be set whenever the validation of the input yields an error. If all is well, 'errors' is either not set or equal to 0.

[1] Note that autocomplete is a non-standard function that doesn't work in every browser.

Here is a description of the various properties.

  • type: the type of the input element, one of the F_* constants defined at the top of this file.
  • name: the name to uniquely identify the input element
  • value: the current value of the element, this value needs to be displayed in the dialog
  • rows: the number of text rows for this element. This applies only to generic text fields (alphanumerics) and listboxes.
  • columns: the number of characters to show in the input element. This applies only to text inputs (not lists or checkboxes).
  • minlength: the minimum number of characters that need to be entered by the user. If 0, the field can be left empty.
  • maxlength: the maximum number of characters that can be entered by the user. Note that this number is no necessarily the same as the number of columns to display (or even the product of columns and rows).
  • decimals: the number of decimals in the fraction of real numbers
  • minvalue: the minimum value that needs to be entered. This applies to numeric fields (integer, real) and also to dates and times.
  • maxvalue: the maximum value that can be entered. This applies to numeric fields (integer, real) and also to dates and times.
  • options: this is a list (array) of key-value-pairs that identify the allowable values for a listbox or radio buttons. The key is used as the fields value and the value is the descriptive title of the option.
  • label: this is the text that is displayed _before_ the input element. It is used to indicate the purpose of the input element.
  • accesskey: this is a single letter that can be used to access the element via the keyboard by using a key combination like [Alt-A].
  • alt: an alternative text that describes the element (accessibility)
  • class: this identifies the class(es) that need to be associated with this element. This allows for changing the style of the element.
  • viewonly: indicates that this element is not to be changed by the user but that it can be displayed nevertheless
  • tabindex: a number that indicates the order in which fields area accessed when using the [Tab] key to move to the next element.
  • title: a descriptive title that is displayed when the mouse is hovering over the element
  • hidden: identifies a field that should be part of the dialog, but not visible to the user. Note that by specifying a hidden list, it is possible to validate the value of the hidden input against the list of acceptable values once it returns from the user. However, one should never trust the value of a field that is sent in 'hidden' form, because after all it is still user input, no matter what.
  • autocomplete: this is a browser-specific attempt to prevent the browser from remembering data entered in a text input field. This does not work in every browser so it is a 'best effort' feature at the most.
  • id a unique (within the document) identifier for this input element. This id is used to link a label to an input. The id should start with a letter. The corresponding label is identified by appending the string '_label' to the id.

  • errors: the number of errors encountered after validating the value of this element
  • error_messages: an array of messages identifying the problems encountered with this element during validation

Constants
ATTR_CLASS_ERROR = error (line 215)
ATTR_CLASS_VIEWONLY = viewonly (line 216)
BUTTON_CANCEL = cancel (line 219)
BUTTON_DELETE = delete (line 222)
BUTTON_DONE = done (line 221)
BUTTON_EDIT = edit (line 226)
BUTTON_GO = go (line 225)
BUTTON_NO = no (line 224)
BUTTON_OK = ok (line 218)
BUTTON_SAVE = save (line 220)
BUTTON_YES = yes (line 223)
F_ALPHANUMERIC = alphanumeric (line 200)
F_CHECKBOX = checkbox (line 207)
F_CSRFTOKEN = csrftoken (line 213)
F_DATE = date (line 203)
F_DATETIME = datetime (line 205)
F_FILE = file (line 211)
F_INTEGER = integer (line 201)
F_LISTBOX = listbox (line 208)
F_PASSWORD = password (line 206)
F_RADIO = radio (line 209)
F_REAL = real (line 202)
F_RICHTEXT = richtext (line 212)
F_SUBMIT = submit (line 210)
F_TIME = time (line 204)
Functions
accesskey_from_string (line 1557)

return the ASCII-character that follows the first tilde in a string

this returns the ASCII-character that follows the first tilde in the string (if any). This is the character that could be added as an accesskey to some HTML tag, e.g. a label or an input. The character is converted to upper case.

Note that a tilde followed by a UTF-8 sequence of 2 or more bytes does NOT yield a hotkey at all but an empty string instead.

  • return: the hotkey character or an empty string
string accesskey_from_string (string $string)
  • string $string: the string to process
accesskey_tilde_to_underline (line 1528)

replace tilde+character with emphasised character to indicate accesskey

this replaces the combination of a tilde and the character following it with $tag_open followed by the character followed by $tag_close.

Example: accesskey_tilde_to_underline("~Username") yields "<u>U</u>sername" accesskey_tilde_to_underline("Pass~word",'','') yields "Password" accesskey_tilde_to_underline("~Role",'','') yields "Role"

Note that we only accept ASCII here: if a tilde is followed by a non-ASCII-character (e.g. the first byte of a multibyte UTF-8 sequence) we silently ignore and still 'eat' the tilde.

  • return: the processed string
string accesskey_tilde_to_underline (string $string, [string $tag_open = '&lt;u&gt;'], [string $tag_close = '&lt;/u&gt;'])
  • string $string: the string to process
  • string $tag_open: the tag that starts the emphasis
  • string $tag_close: the tag that ends the emphasis
dialog_buttondef (line 1390)

shortcut for generating a dialogdef for a button

this constructs an array describing a button. The button definition is bare bones but it includes name, class, value and optionally a title. If no $value is specified, a translated value is retrieved for the button. If no $title is specified, a title indicating the hotkey is constructed. This more or less works around the problem that hotkeys cannot be visualised in an input type="submit" button (It is possible in a button tag, but we don't use that because it requires HTML 4. Maybe later...)

If $button_type is not one of the defined values BUTTON_* the variable itself is used as name, class and as a key for the translation of value unless a $value is specified.

Typical use:

$dialogdef = array(...,'button_ok' => dialog_buttondef(BUTTON_OK));

Another example defining a non-standard button:

$button = dialog_buttondef('button_foo','~Foo','Do not press this button!');

  • return: ready-to-use $item for a dialog
array dialog_buttondef (string $button_type, [string $value = ''], [string $title = ''])
  • string $button_type: one of the predefined button constants, e.g. BUTTON_OK
  • string $value: the label used for display including hotkey, eg. '~Yes' or '~Cancel'
  • string $title: the text displayed via a mouseover
dialog_csrftoken (line 1469)

shortcut for generating a dialogdef for a csrftoken

this constructs an array describing the csrftoken. Basically we are constructing a hidden field already filled with data from the current session (see get_csrftoken()). Since get_csrftoken() already fills in the 'name' and 'value', we only have to add the 'type' and set the field to 'hidden'.

  • return: ready-to-use $item for a dialog
array dialog_csrftoken ()
dialog_get_class (line 1489)

construct a space-delimited list of classes that apply to this item

this constructs a string with applicable classes for this element. if the item has validation errors, the class ATTR_CLASS_ERROR is added, if the item is viewonly, the class ATTR_CLASS_VIEWONLY is added. This allows for the CSS to change the style depending on these situations.

  • return: a space-delimited list of applicable classes
string dialog_get_class (array &$item, [string $class = NULL])
  • array &$item: the parameters that describe the dialog input element
  • string $class: class to start with, otherwise use $item['class']
dialog_get_label (line 312)

construct a label for a dialog input element

this constructs the label for an input. It is built inside a label-tag, possibly with these attributes: id, for, accesskey, class, title. The class is a special case: if there were errors the class 'ATTR_CLASS_ERROR' is added to the class attribute, in case of viewonly the class ATTR_CLASS_VIEWONLY' is added too. (Note that the latter shouldn't happen: how can a viewonly field yield any errors at all unless someone is trying to crack the program?)

Because some browsers require that the label of a listbox is linked to the select tag (done via 'id' and 'for'), we MUST have some 'id' for that particular tag. If it is not there, we generate one and add it automagically.

  • return: ready-to-use HTML
  • todo: if we let the hotkey from the label prevail and add it to the input tag, why add a hotkey to the label too?
string dialog_get_label (array &$item)
  • array &$item: the parameters that describe the dialog input element
dialog_get_widget (line 372)

construct an actual HTML input widget for dialog input element

this constructs the actual HTML-code for a dialog input element. If the input element is 'hidden', we generate a minimalistic hidden field with no labels, accesskeys or whatever: basically just a name-value-pair to communicate to a subsequent form. Note that we force a field of type F_CSRFTOKEN to be hidden too, even if it isn't set to be hidden.

If the item is genuine (it has a name and a type), we construct the input using a workhorse routine.

  • return:
    1. or more lines of ready-to-use HTML
  • todo: we now only cater for buttons via input type="submit" without the option to visualise the accesskey. Using the button tag could solve that, but button is not defined beforde HTML 4.01. What to do?
  • todo: we could manipulate the title attribute of input strings like "please enter a number between {MIN} and {MAX}" based on the various value properties instead of just displaying the title. oh well, for a future version, perhaps...
  • usedby: Theme::get_jumpmenu()
array|string dialog_get_widget (array &$item)
  • array &$item: the parameters that describe the dialog input element
dialog_get_widget_file (line 1317)

construct an input field for file upload

this constructs an input widget for uploading files. This usually includes a button to browse the user's local file system (depends on browser).

Note that it is NOT possible to 'preload' a value in this input field; any predefined value is ignored by the browser. As a workaround we _could_ show the $value to the user using an additional comment, e.g. by adding it to the label or something. For now, we simply do nothing with the value.

The properties recognised translate to the following HTML-code/attributes

name      : name
value     : value (see note above)
accesskey : accesskey
columns   : cols (textarea) or size (input type="text")
alt       : alt
class     : class (also depends on viewonly and errors)
tabindex  : tabindex
id        : id
title     : title
multiple  : multiple
viewonly  : disabled AND addition of ATTR_CLASS_ERROR to class list (if viewonly == TRUE)
errors    : addition of ATTR_CLASS_ERROR to class list (if errors > 0)

  • return: one or more lines of ready-to-use HTML
  • todo: if we let the hotkey from the label prevail and add it to the input tag, why add a hotkey to the label too?
  • todo: should we do something with an um-empty $value? If so, waht? The browser ignores this...
array|string dialog_get_widget_file (array &$item, string $name, mixed $value)
  • array &$item: the parameters that describe the dialog input element
  • string $name: the name of the input element ('fieldname')
  • mixed $value: the (current) value of the input element to show ('field value')
dialog_get_widget_listbox (line 1044)

construct a listbox

this constructs a listbox

The number of lines in the result depends on the number of items in the options array in $item. The result always starts with a SELECT opening tag, followed by N OPTION tags and finally a SELECT closing tag.

There are two different ways to specify the options. The simple way is to have a single options array with 'value' => 'option text' pairs. In this case the available properties such as title, class and viewonly are copied from the corresonding generic properties in the $item array,

The other way is to have an array of arrays like this:

    $item['options'] = array('1'=>array('title'=>'...','option'=>'...'),2 => array(...));

This allows for setting properties of individual options, e.g. one of the options could be made viewonly while the others are still selectable.

The properties recognised translate to the following HTML-code/attributes

name      : name
value     : value AND perhaps 'selected' if value matches option value
accesskey : accesskey
alt       : alt
class     : class (also depends on viewonly and errors)
tabindex  : tabindex
id        : id
title     : title
viewonly  : disabled AND addition of ATTR_CLASS_ERROR to class list (if viewonly == TRUE)
errors    : addition of ATTR_CLASS_ERROR to class list (if errors > 0)
label     : tilde+letter may change the accesskey

Note that the options within the SELECT tag are indented 2 spaces for readability.

  • return: 2 or more lines of ready-to-use HTML
array dialog_get_widget_listbox (array &$item, string $name, mixed $value, string $f_type)
  • array &$item: the parameters that describe the dialog input element
  • string $name: the name of the input element ('fieldname')
  • mixed $value: the (current) value of the input element to show ('field value')
  • string $f_type: the type of the field (eg text, number, date, time, ...)
dialog_get_widget_radiocheckbox (line 919)

construct a checkbox or 1 or more radiobuttons

this constructs a checkbox or a list of radiobuttons.

Note: because a checkbox and radionbuttons are very similar, they are handled in the same workhorse routine. Maybe we should split this in the name of code clarity. Oh well...

If we are generating a checkbox, the result looks something like this:

<input type="checkbox" value="1" checked ...><label ...>option text<label>

If we are generating radiobuttons, the result looks something like this:

<input type="radio" value="1" checked ...><label ...>option 1 text<label>
<input type="radio" value="2" ...><label ...>option 2 text<label>
<input type="radio" value="3" ...><label ...>option 3 text<label>

The number of lines in the result depends on the number of items in the options array in $item. In case of a checkbox there should only be one, in case of radiobuttons there should be more than 1.

There are two different ways to specify the options. The simple way is to have a single options array with 'value' => 'option text' pairs. In this case the available properties such as title, class and viewonly are copied from the corresonding properties in the $item array,

The other way is to have an array of arrays like this:

    $item['options'] = array('1'=>array('title'=>'...','option'=>'...'),2 => array(...));

This allows for setting properties of individual options, e.g. one of the radio buttons could be made viewonly while the others are still selectable.

Note that such a non-simple array of arrays doesn't make much sense for a single, simple checkbox.

The properties recognised translate to the following HTML-code/attributes

name      : name
value     : value AND perhaps 'checked' if value matches option value
accesskey : accesskey
alt       : alt
class     : class (also depends on viewonly and errors)
tabindex  : tabindex
id        : id
title     : title
viewonly  : disabled AND addition of ATTR_CLASS_ERROR to class list (if viewonly == TRUE)
errors    : addition of ATTR_CLASS_ERROR to class list (if errors > 0)
label     : tilde+letter may change the accesskey

Note: In case of radiobuttons, the document-wide unique id is constructed from the specified id by appending an underscore and an indexnumber (except for the first item in te list). This id can be overruled by an id specified in the options array-of-arrays.

Even when an item has an explicit accesskey, the access key can be overruled by the the 'hotkey' derived from a tilde+letter combination in the options array, either in the simple case or in case of and array-of-arrays.

Note that also the generic title can be overruled by a title that is defined in the options array-of-arrays.

  • return:
    1. or more lines of ready-to-use HTML
array|string dialog_get_widget_radiocheckbox (array &$item, string $name, mixed $value, string $f_type)
  • array &$item: the parameters that describe the dialog input element
  • string $name: the name of the input element ('fieldname')
  • mixed $value: the (current) value of the input element to show ('field value')
  • string $f_type: the type of the field (eg text, number, date, time, ...)
dialog_get_widget_richtextinput (line 1149)

construct an input field using the user's preferred editor

this constructs an input for rich text like a page with HTML-code. Most users will probably have selected the CKeditor. However, there is also the option to use the so-called 'plain' editor, which is nothing more than a textarea in disguise.

The properties recognised translate to the following HTML-code/attributes

name      : name
value     : value
accesskey : accesskey
rows      : rows
columns   : cols
maxlength : maxlength
alt       : alt
class     : class (also depends on viewonly and errors)
tabindex  : tabindex
id        : id
title     : title
viewonly  : disabled AND addition of ATTR_CLASS_ERROR to class list (if viewonly == TRUE)
errors    : addition of ATTR_CLASS_ERROR to class list (if errors > 0)

For maximum compatibility we not only retain FCKEditor 2.6.5 (2359) but also CKEditor 3.6.6.2 (7696) next to CKEditor 4.4.5 (25cdcad). The actual editor to use depends on the system wide choice and user preference. For compatibility the latest editor is configured to be 'ckeditor' whereas the older version 3 is now selected with 'ckeditor3'. This means that existing 'ckeditor'-users will be moved to CKEditor4 whereas 'plain' and 'fckeditor' users will see no change. (November 2014).

  • return:
    1. or more lines of ready-to-use HTML
  • todo: if we let the hotkey from the label prevail and add it to the input tag, why add a hotkey to the label too?
array|string dialog_get_widget_richtextinput (array &$item, string $name, mixed $value,  $f_type)
  • array &$item: the parameters that describe the dialog input element
  • string $name: the name of the input element ('fieldname')
  • mixed $value: the (current) value of the input element to show ('field value')
  • $f_type
dialog_get_widget_submit (line 810)

construct a submit button

this constructs a submit button. For compatibiliy we use a simple input of type submit because the button widget is only available since HTML 4. We may change that in the future, and force everyone to use at least HTML 4. For now it is as it is.

Note that the label of the button is retrieved from $value rather than from the label property. We do use the $value as a string possibly containing hotkeys (via prepending a letter with a tilde) and we also set the accesskey to that value. However, it is different from other widgets because an input cannot display underlines (a button can).

The properties recognised translate to the following HTML-code/attributes

name      : name
value     : value
accesskey : accesskey
alt       : alt
class     : class (also depends on viewonly and errors)
tabindex  : tabindex
id        : id
title     : title
viewonly  : disabled AND addition of ATTR_CLASS_ERROR to class list (if viewonly == TRUE)
errors    : addition of ATTR_CLASS_ERROR to class list (if errors > 0)

  • return:
    1. or more lines of ready-to-use HTML
array|string dialog_get_widget_submit (array &$item, string $name, mixed $value, string $f_type)
  • array &$item: the parameters that describe the dialog input element
  • string $name: the name of the input element ('fieldname')
  • mixed $value: the button's label possibly including a tilde indicating hotkey
  • string $f_type: the type of the field (eg text, number, date, time, ...)
dialog_get_widget_textinput (line 716)

construct an input field, usually for text input OR a textarea for multiline input

this constructs most variations on text fields, including password fields Many of the defined field types (the F_* constants) can be handled via a simple input of type text. The semantics of the field (eg. is it an integer, a real) have no impact on the HTML-input: at that level it is still plain text. However, for a password we use the password type in order to make the value display as asterisks. If the number of rows is more than 1, the input element becomes a text area. Note that is generally only applies to F_ALPHANUMERIC but that is not enforced here (you can make a multiline F_DATE, even though it doesn't make much sense).

The properties recognised translate to the following HTML-code/attributes

name         : name
value        : value
accesskey    : accesskey
rows         : rows (textarea only)
columns      : cols (textarea) or size (input type="text")
maxlength    : maxlength
alt          : alt
class        : class (also depends on viewonly and errors)
tabindex     : tabindex
id           : id
title        : title
autocomplete : autocomplete [1]
viewonly     : disabled AND addition of ATTR_CLASS_ERROR to class list (if viewonly == TRUE)
errors       : addition of ATTR_CLASS_ERROR to class list (if errors > 0)

[1] Note that autocomplete is a non-standard function that doesn't work in every browser.

  • return:
    1. or more lines of ready-to-use HTML
  • todo: if we let the hotkey from the label prevail and add it to the input tag, why add a hotkey to the label too?
array|string dialog_get_widget_textinput (array &$item, string $name, mixed $value, string $f_type)
  • array &$item: the parameters that describe the dialog input element
  • string $name: the name of the input element ('fieldname')
  • mixed $value: the (current) value of the input element to show ('field value')
  • string $f_type: the type of the field (eg text, number, date, time, ...)
dialog_quickform (line 250)

construct a generic form with a dialog

this constructs an HTML form with a simple dialog where

  • every label and every widget has its own line (enforced by a BR-tag)
  • label/widget-combinations are separated with a P-tag
  • buttons are stringed together on a single line (ie no trailing BR)
This should be sufficient for many dialogs. If the layout needs to be more complex a custom dialog can always be constructed using functions dialog_get_label() and dialog_get_widget().

array dialog_quickform (string $href, array &$dialogdef, [string $method = 'post'], [string|array $attributes = ''])
  • string $href: the target of the HTML form
  • array &$dialogdef: the array which describes the complete dialog
  • string $method: method to submit data to the server, either 'post' or 'get'
  • string|array $attributes: holds the attributes to add to the form tag
dialog_validate (line 456)

validate and check values that were submitted via a user dialog

this steps through the definition of a dialog and retrieves the values submitted by the user via $_POST[]. The values are checked against the constraints (e.g. minimum string length, date range, etc.). If the submitted value is considered valid, it is stored in the corresponding value of the dialogdef element, maybe properly reformatted (in case of dates/times/datetimes). If there were errors, these are recorded in the dialog definition element, in the form of one or more readable error messages. Also the error count (per element) is incremented. This makes it easy to

  • inform the user about what was wrong with the input data
  • determine whether there was an error at all (if $dialogdef[$k]['errors'] > 0).
Note that this routine has the side effect of filling the dialog array with the data that was submitted by the user via $_POST. If the validation is successful, the data is ready to be saved into the database. If it is not, the data entered is still available in the dialogdef which makes it easy to return to the user and let the user correct the errors without losing all the data input because of a silly mistake in some input field.

Update 2009-03-17: We no longer validate the view-only fields because these fields are not POST'ed by the browser and hence cannot be validated. This also means that there is no value set from $_POST for those fields.

Update 2011-09-29: added UTF-8 validation, replace with U+FFFD (Unicode replacement character) on fail

  • return: TRUE if all submitted values are considered valid, FALSE otherwise
  • todo: add an error message to
  • usedby: ConfigAssistant::save_data()
bool dialog_validate (array &$dialogdef)
  • array &$dialogdef: the complete dialog definition; contains detailed errors and/or reformatted values
valid_datetime (line 1593)

check validity of date, time or datetime

this checks the validity of dates and times. If all tests are passed successfully, the input value is reformatted in the standard format corresponding with that field type:

  • F_DATE becomes yyyy-mm-dd (with leading zeros for month or day where applicable)
  • F_TIME becomes hh:mm:ss (with leading zeros when applicable)
  • F_DATETIME is combination of F_DATE and F_TIME glued together with a space: yyyy-mm-dd hh:mm:ss
Valid values for dates are within the range 0000-01-01 ... 9999-12-31 (but note that the year is always displayed with 4 digits). This routine takes leap years into account the same way the standard function checkdate() does.

Valid values for times are between 00:00:00 and 23:59:59. Note that we don't deal with leap seconds or other fancy stuff (this is not rocket science): KISS. Usually we only need times to determine an embargo date/time anyway.

Also, this routine doesn't know about time zones and daylight savings time.

  • return: TRUE if the input was valid, FALSE otherwise
bool valid_datetime (string $f_type, string $input, string &$output)
  • string $f_type: indicates the field type we are expecting, can be F_DATE, F_TIME or F_DATETIME
  • string $input: the string that needs to be checked
  • string &$output: if the input is valid, this contains a properly formatted value

Documentation generated on Tue, 28 Jun 2016 19:09:10 +0200 by phpDocumentor 1.4.0