|
Depending
on the requirements of your situation, you can specify one or more
of the following patterns to control how field values, such as text
fields, numeric fields, and date/time fields are formatted at run
time:
-
A display pattern, which describes how data will be displayed
in the form. If you define an initial default value, it is formatted
according to the display pattern. The display pattern is also responsible
for formatting user input and any bound values retrieved at run
time.
-
An edit pattern, which describes the syntax for entering
data into a date/time field, numeric field, text field, or password
field at run time.
-
A validation pattern, which is used to validate user input
at run time.
-
A data pattern, which describes the syntax of bound or saved
data.
The formatting options that you choose will depend on the purpose
of your form. For example, if you are designing an interactive form,
for each field you should define an edit pattern to process user
input and a validation pattern to validate the input. You would
only define a data pattern if the fields are bound to a data source.
Keep in mind that if you specify only an Edit pattern for a Numeric
Field or Decimal fields object, form fillers can still enter alphabetic
characters in the field. To avoid this behaviour, do one of the
following actions:
-
Do not specify just an Edit pattern. Ensures that Acrobat
and Adobe Reader filter out unwanted alphabetic characters.
-
Specify Edit and Display patterns. Ensures that the data
is formatted correctly according to the Display pattern.
-
Specify Edit and Validation patterns. Ensures that the value
is rejected and the field is cleared when a form filler enters an
alphabetic character.
When to use patterns
Use
patterns to control how field values are processed at run time.
For example, users can enter letters and numbers into a text field
and any special punctuation or spacing can be applied automatically
according to a predefined pattern before the value is displayed.
Capturing and displaying user input
If you are creating a form to capture data, you can specify
how data should be formatted. You specify how the data should appear
using a display pattern. If you do not specify a display pattern,
the data appears according to Designer defaults.
If users will be entering data that does not match the Designer
defaults, you must specify an edit pattern. The edit pattern describes
the syntax of the user input. Given the pattern, the run-time application
converts the user input into a raw value and then formats the value
according to the display pattern.
If you are designing an interactive form, consider what user
input must be validated. For example, a text field may or may not
require validation depending on usage. A multiple line text field
allowing the form filler to enter a comment does not need to be
validated. Similarly, a numeric field will automatically prevent
the form-filler from entering any non-numeric data. However, if
the data has to be restricted to a specific range of numbers, you
will want to validate the user input. You can choose to display
a custom message to prompt users for a correct value at run time.
If you do not specify a custom message, the system generates one
automatically.
Remember that by using the options on the Form Validations tab
in the Form Properties dialog box, you can configure how Acrobat
displays validations messages, highlights failed or mandatory fields
that contain invalid data or no data, and sets the focus on the
first field that fails to validate. See
Displaying validation errors in Acrobat
.
Note:
User
input can be processed through FormCalc formulas and JavaScript
scripts (for example, a script can request the raw value of a field).
Because formulas and scripts operate on raw and formatted values,
it is important to validate those fields where input is restricted.
One example of how an edit and validation pattern may be used
together is a credit card or social security number entry. You could
define a text field with the following edit patterns:
text{9999-9999-9999-9999}|text{9999
9999 9999 9999} for credit cards
or
text{999-99-9999}|text{999
99 9999} for a US social security number
In both cases, the user may enter the number with hyphen(-),
space ( ), or just the 16 or 9 digit number. The canonical, or simplest
form of the number is the 16 or 9 digit number.
You may also choose to add the following validation pattern:
text{9999999999999999}
or
text{999999999}
In this case, only the number is stored and the validation checks
for the correct number of digits. However, in this case, it might
be more useful to specify a validation script rather than a pattern.
There are algorithms that will checksum a credit card number to
ensure that it looks like a valid credit card number and not just
a random 16 digit number. An example is the Luhn Algorith for credit
cards.
The result is a form that has a text field where the edit pattern
allows user entry in one of three typical ways for typing a credit
number, and the validation runs a script that validates that the
number looks like a valid credit card number.
Retrieving and displaying bound data
If bound data will be merged with a form, you can specify
how the data should be formatted for display using a display pattern.
If you do not specify a display pattern, the data is displayed according
to Designer defaults.
If the bound data does not match Designer defaults, you must
specify a data pattern. The data pattern describes the syntax of
the bound data. Given the pattern, the run-time application converts
the retrieved data into raw values and then formats them for display.
Defaults for value formatting
Default values must conform to the following
rules, depending on the type of field.
|
Field
|
Rule
|
|
Date/Time Field
|
A default date/time value must conform to
the short format for the locale specified for the date/time field.
However, by default, Designer displays the default value in the
medium locale format at both design time and run time.
For
example, consider a form with a Date/Time Field set to use the German
(Germany) locale. You enter the default value for a date in the short
format DD.MM.YY. After you change the focus to another field, the
value specified in the field on the page is displayed in the medium format
DD.MM.YYYY. The formatted value also appears in the medium format
if you view the form in the Preview PDF tab.
Note:
At
run time, by default, form fillers must edit the value of date/time
fields using the short format for the locale specified for the field.
If you specify an Edit Pattern on the Edit tab in the Patterns dialog
box (Field tab > Patterns), that pattern overrides the short
format, and users must enter data that conforms to the Edit Pattern.
|
|
Numeric Field or Decimal Field
|
A default numeric value can be any integer
or any decimal number that contains a single radix point. The radix
character can be either a “.” (period) or “,” (comma) depending
on the locale selected. Thousands separators (or grouping symbols)
and currency symbols are not valid as part of the default value.
For
example, if a numeric field is set to the locale English (USA),
and you specify the default value $1,234.56, both the currency symbol
“$” (dollar sign) and the thousands separator “,” (comma) are not
valid.
|
|
Text Field
|
A default text value (including passwords)
can be any alphanumeric text string, including spaces.
|
Note:
Only those fields listed in the table have default
values that must conform to locale-specific formatting.
To specify a default value
Date/time fields, numeric fields,
and text fields can display an initial (default) value when the
form is opened. The value can be derived from a run-time property,
or you can specify the value explicitly in Designer. The value can
also be derived from an external data source through binding. At
run time, Designer formats field default values according to the
locale specified for each field.
-
Select a date/time field, decimal field, numeric field,
or text field.
-
In the Object palette, click the Field tab. Select a locale
from the Locale list.
-
In the Object palette, click the Value tab. Type the value
into the Default box.
The default value must be specified
in locale-sensitive format.
Note:
If the data is
bound and a data pattern has been specified, the value must match
the data pattern specified in the Binding tab.
To specify a display pattern
At run time, Designer displays date,
time, and numeric field values in locale-sensitive format. If you
want to display a field value in a format other than the default,
you can specify the custom pattern by clicking the Patterns button
on the Field tab.
Note:
Drop-down lists support custom user entries,
but a display pattern for custom user entries cannot be specified.
You can write a script to format the user input if required.
Because the display pattern describes how data will be displayed
in the form, all default values, user-entered values, and values
retrieved from a database are converted to the format described
by the display pattern.
Note:
Dates earlier than January 1, 1900 are not formatted
by the display pattern.
-
Select the date/time field, numeric field, or text field.
-
In the Object palette, click the Field tab.
-
Click Patterns and either select one of the predefined display
patterns from the Select Type list or type a custom pattern in the
Pattern box.
To prompt users to enter data
Prompts
are useful for situations where users are expected to enter data
or make a selection. You can write a message to prompt users to
enter a value into a date/time field, numeric field, text field,
password field, or drop-down list, or prompt users to select an
option from a drop-down list, list box, or radio button group.
Recommending that users enter data
You can recommend that users enter data in a field but
still let them submit the form if they do not. If a user enters
data in the field, leaves the field and then clears it, a message
box appears. A custom message appears if one written in the Empty
Message box. A standard empty field message appears if you do not
type a custom message. A message only appears if there was data
in the field, the value was deleted, and the user exited the field
without re-entering data. If the user never attempts to enter data
in the field and tries to submit the form, a field is required message
appears. The user can choose to ignore the message and submit the
form. Choose User Entered - Recommended to recommend that users enter
data in a field.
Requiring that users enter data
You can make it mandatory for users to enter data in a
field before they can submit a form. If a user enters data in the
field, tabs out, and then returns to clear it, a message box appears.
A custom message appears if one written in the Empty Message box.
A standard empty field message appears if you do not type a custom
message. A message only appears if there was data in the field,
the value was deleted, and the user exited the field without re-entering
data. If the user never attempts to enter data in the field and
tries to submit the form, a field is required message appears. Choose
User Entered - Required to make it mandatory that users enter data
in a field.
Remember that by using the options on the Form Validations tab
in the Form Properties dialog box, you can configure how Acrobat
displays validations messages, highlights failed or mandatory fields
that contain invalid data or no data, and sets the focus on the
first field that fails to validate. See
Displaying validation errors in Acrobat
.
Note:
If users do not enter a value into the field
and try to submit the form, the error message field is required
appears. However, users can save and close a PDF form without providing
recommended or required values. In this case, no messages appear
to prompt users for input.
-
Select the field, drop-down list, list box, or radio
button group.
-
In the Object palette, click the Value tab. From the Type
list, select one of these options:
-
In the Empty Message box, type the prompt. If applicable,
the prompt should specify the required input format. For example,
if you defined an edit pattern, the user input must conform to the
edit pattern.
To specify an edit pattern
At
run time, Designer displays date, time, numeric, and decimal field
values in locale-sensitive format. If you want to permit form fillers
to edit field values in a format other than the locale-sensitive
default, you can specify an Edit Pattern on the Field tab. If the
user’s input does not conform to the edit pattern, the data is input
as-is.
If you specify only an Edit pattern for a Numeric or Decimal
field object, form fillers can still enter alphabetic characters
in the field.
The edit pattern can be different than the display pattern. For
example, because it is easier for users to enter short dates and
read long dates, you could consider specifying a short date for
a date/time field’s edit pattern and a long date for its display
pattern. When the display and edit patterns are different, the value
is formatted to match the display pattern as soon as the user exits
the field.
Note:
This option is not available when the Type option
in the Value tab of the Object palette is set to Protected, Calculated
- Read Only or Read Only.
-
Select the date/time field, numeric field, text field,
or password field.
-
In the Object palette, click the Field tab.
-
Click Patterns, click the Edit tab, and either select one
of the predefined display patterns from the Select Type list or
type a custom pattern in the Pattern box.
To validate user input
Three separate validations
are possible for any field. The order of initiation of these validations
is as follows:
-
Test the field for null content.
-
Verify the format of the field value against a specific field
pattern. For more information about field patterns, see
Simple patterns
.
-
Invoke a validation script.
You can define a validation pattern to validate user input for
date/time fields, numeric fields, text fields, and password fields.
By default, null entries are not accepted when a value is required.
Raw values are compared to the validation pattern directly and,
if the raw value matches the validation pattern, it is formatted
for display.
If the user-entered
value does not match the validation pattern, a programming error
or warning appears. The error/warning is trapped by Acrobat, Adobe
Reader, or Forms, which returns a message to the user automatically.
If an edit pattern has not been specified and the user input does not
match Designer defaults, validation fails.
A validation
message appears if objects that require values contain null values
and the user attempts to submit data to Forms.
Note:
Users can save and close a PDF form without
providing required values. In this case, no validation is performed.
If needed, you can write a custom validation pattern message
to replace the default error or warning message.
In addition to a validation pattern, or in cases where a validation
pattern is not supported (for example, for radio button groups and
check boxes), you can validate user input by using a validation
script. Validating input through a script ensures that the data
is acceptable for your application. A custom message and run-time
error or warning is also supported in this case.
Remember that by using the options on the Form Validations tab
in the Form Properties dialog box, you can configure how Acrobat
displays validations messages, highlights failed or mandatory fields
that contain invalid data or no data, and sets the focus on the
first field that fails to validate. (See
Displaying validation errors in Acrobat
.)
You can dynamically populate a validation pattern
message with a value from a data source. This option allows you
to ensure that users enter a valid value in the field.
To define a validation pattern and custom message
-
Select the date/time field, numeric field, text
field, password field, drop-down list, or list box.
-
In the Object palette, click the Value tab.
-
Click Validation Pattern and either select one of the predefined
validation patterns from the Select Type list or type a custom pattern
in the Pattern box.
-
In the Validation Pattern Message box, type a message to
prompt users to enter the correct value. The message should specify
the required input format. To start a new line in the message, press
Ctrl+Enter.
-
To have a programming error to appear instead of a warning,
select the Error option.
To display a message when an attached script detects unacceptable input
-
Select
the date/time field, numeric field, text field, password field,
drop-down list, list box, check box, or radio button group.
-
In the Object palette, click the Value tab. In the Validation
Script Message box, type the message.
-
To have a programming error appear instead of a warning,
select the Error option.
To specify a data pattern
Data binding options enable you to build
a form that captures data for enterprise infrastructures and/or
use an external data source to populate a form at run time. For
example, given appropriate binding information (see
Binding fields to a data source
) and access to the data source (see
Working with Data Sources
), Acrobat and Adobe Reader can import and
display data from an OLEDB database when the form is opened. Objects
can also be bound to an XML schema, an XML file, or a WSDL data
source.
Acrobat,
Adobe Reader, and Forms interpret the data-binding properties to
store captured data and parse retrieved data. By default, an object’s
data is stored and merged according to Adobe data-merging rules. When
a form opens in Acrobat or Adobe Reader, or is rendered by Forms,
the field values are populated from the data source. Any changes
to a field’s value by the user are committed to the associated data
source when the form is saved in Acrobat or Adobe Reader or the
data is submitted to Forms.
If the data is not bound to a data source (for example, if the
form data will be returned by email), the data pattern specifies
the format that the data is saved in. If you do not create a data
pattern, the data will be saved in canonical format. If a form may
be filled by end users in a variety of locales or if the data may
be returned to more than one locale, having the data in canonical
format helps ensure that it is interpreted the same way by all users.
You can
specify data patterns for date/time fields, numeric fields, text
fields, and password fields. If the data pattern prevents Acrobat
or Adobe Reader, or Forms from parsing a retrieved value, the value appears
in the form unchanged (it is not formatted for display).
-
Select the date/time field, numeric field, text field,
or password field.
-
In the Object palette, click the Field tab.
-
Click Patterns, click the Data tab, and either select one
of the predefined data-binding patterns from the Select Type list
or type a custom pattern in the Pattern box.
Simple patterns
Simple
patterns can be used to format the values of date/time fields, numeric fields,
text fields, and password fields. They each have their own rules
governing the valid formation of patterns. There is a limited set
of characters that you can use in a pattern, and the syntax of a
valid pattern differs among date/time fields, numeric fields, text
fields, and password fields.
For information about the valid characters that you can use in
a pattern and examples of valid constructs, see one of the sections
listed below. For information about complex patterns for a date/time
field, numeric field, or text field, see
Complex field patterns
.
Locales
A
locale
is a standard term
used when developing international standards to identify a particular
nation (language, country or region). For the purposes of FormCalc,
a
locale
defines the format of dates, times, numeric, and
currency values relevant to a specific nation or region so that
users can use the formats they are accustomed to.
Each locale
is comprised of a unique string of characters called a
locale identifier
.
The composition of these strings is controlled by the international
standards organization (ISO) Internet Engineering Task Force (IETF), a
working group of the Internet Society (
www.isoc.org
).
Locale identifiers consist of a language part, a country or region
part, or both. The following table lists valid locales for this
release of Designer.
|
Language
|
Country or Region
|
ISO Code
|
|
Arabic
|
Algeria
|
ar_DZ
|
|
Arabic
|
Bahrain
|
ar_BH
|
|
Arabic
|
Egypt
|
ar_EG
|
|
Arabic
|
Iraq
|
ar_IQ
|
|
Arabic
|
Jordan
|
ar_JO
|
|
Arabic
|
Kuwait
|
ar_KW
|
|
Arabic
|
Lebanon
|
ar_LB
|
|
Arabic
|
Libya
|
ar_LY
|
|
Arabic
|
Morocco
|
ar_MA
|
|
Arabic
|
Oman
|
ar_OM
|
|
Arabic
|
Qatar
|
ar_QA
|
|
Arabic
|
Saudi Arabia
|
ar_SA
|
|
Arabic
|
Sudan
|
ar_SD
|
|
Arabic
|
Syria
|
ar_SY
|
|
Arabic
|
Tunisia
|
ar_TN
|
|
Arabic
|
United Arabian Emirates
|
ar_AE
|
|
Arabic
|
Yemen
|
ar_YE
|
|
Armenian
|
Armenia
|
hy_AM
|
|
Azerbaijani-Cyrillic
|
Azerbaijan
|
az_Cyrl_AZ
|
|
Azerbaijani-Latin
|
Azerbaijan
|
az_Latn_AZ
|
|
Basque
|
Spain
|
eu_ES
|
|
Bosnain
|
Bosnia and Herzegovina
|
bs_BA
|
|
Bulgarian
|
Bulgaria
|
bg_BG
|
|
Catalan
|
Spain
|
ca_ES
|
|
Chinese
|
People’s Republic of China (Simplified)
|
zh_CN
|
|
Chinese
|
Hong Kong S.A.R., China
|
zh_HK
|
|
Chinese
|
Taiwan (Traditional)
|
zh_TW
|
|
Croatian
|
Croatia
|
hr_HR
|
|
Czech
|
Czech Republic
|
cs_CZ
|
|
Danish
|
Denmark
|
da_DK
|
|
Dutch
|
Belgium
|
nl_BE
|
|
Dutch
|
Netherlands
|
nl_NL
|
|
English
|
Australia
|
en_AU
|
|
English
|
Belgium
|
en_BE
|
|
English
|
Canada
|
en_CA
|
|
English
|
Hong Kong S.A.R., China
|
en_HK
|
|
English
|
India
|
en_IN
|
|
English
|
India Rupee
|
en_IN_RUPEE
|
|
English
|
Ireland
|
en_IE
|
|
English
|
New Zealand
|
en_NZ
|
|
English
|
Philippines
|
en_PH
|
|
English
|
Singapore
|
en_SG
|
|
English
|
South Africa
|
en_ZA
|
|
English
|
United Kingdom
|
en_GB
|
|
English
|
United Kingdom Euro
|
en_GB_EURO
|
|
English
|
United States of America
|
en_US
|
|
English
|
U.S. Virgin Islands
|
en_VI
|
|
Estonian
|
Estonia
|
et_EE
|
|
Finnish
|
Finland
|
fi_FI
|
|
French
|
Belgium
|
fr_BE
|
|
French
|
Canada
|
fr_CA
|
|
French
|
France
|
fr_FR
|
|
French
|
Luxembourg
|
fr_LU
|
|
French
|
Switzerland
|
fr_CH
|
|
German
|
Austria
|
de_AT
|
|
German
|
Germany
|
de_DE
|
|
German
|
Luxembourg
|
de_LU
|
|
German
|
Switzerland
|
de_CH
|
|
Greek
|
Greece
|
el_GR
|
|
Hebrew
|
Israel
|
he_IL
|
|
Hindi
|
India
|
hi_IN
|
|
Hungarian
|
Hungary
|
hu_HU
|
|
Indonesian
|
Indonesia
|
id_ID
|
|
Italian
|
Italy
|
it_IT
|
|
Italian
|
Switzerland
|
it_CH
|
|
Japanese
|
Japan
|
ja_JP
|
|
Kazakh
|
Kazakhstan
|
kk_KZ
|
|
Khmer
|
Cambodia
|
km_KH
|
|
Korean
|
Korea
|
ko_KR
|
|
Korean
|
Korea Hanja
|
ko_KR_HANI
|
|
Lao
|
Laos
|
lo_LA
|
|
Latvian
|
Latvia
|
lv_LV
|
|
Lithuanian
|
Lithuania
|
lt_LT
|
|
Malay
|
Malaysia
|
ms_MY
|
|
Norwegian - Bokmal
|
Norway
|
nb_NO
|
|
Norwegian - Nynorsk
|
Norway
|
nn_NO
|
|
Persian
|
Iran
|
fa_IR
|
|
Polish
|
Poland
|
pl_PL
|
|
Portuguese
|
Brazil
|
pt_BR
|
|
Portuguese
|
Portugal
|
pt_PT
|
|
Romanian
|
Romania
|
ro_RO
|
|
Russian
|
Russia
|
ru_RU
|
|
Serbian-Cyrillic
|
Serbia and Montenegro
|
sr_Cyrl_CS
|
|
Serbian-Latin
|
Serbia and Montenegro
|
sr_Latn_CS
|
|
Slovak
|
Slovakia
|
sk_SK
|
|
Slovenian
|
Slovenia
|
sl_SI
|
|
Spanish
|
Argentina
|
es_AR
|
|
Spanish
|
Bolivia
|
es_BO
|
|
Spanish
|
Chile
|
es_CL
|
|
Spanish
|
Columbia
|
es_CO
|
|
Spanish
|
Costa Rica
|
es_CR
|
|
Spanish
|
Dominican Republic
|
es_DO
|
|
Spanish
|
Ecuador
|
es_EC
|
|
Spanish
|
El Salvador
|
es_SV
|
|
Spanish
|
Guatemala
|
es_GT
|
|
Spanish
|
Honduras
|
es_HN
|
|
Spanish
|
Mexico
|
es_MX
|
|
Spanish
|
Nicaragua
|
es_NI
|
|
Spanish
|
Panama
|
es_PA
|
|
Spanish
|
Paraguay
|
es_PY
|
|
Spanish
|
Peru
|
es_PE
|
|
Spanish
|
Puerto Rico
|
es_PR
|
|
Spanish
|
Spain
|
es_ES
|
|
Spanish
|
United States of America
|
es_US
|
|
Spanish
|
Uruguay
|
es_UY
|
|
Spanish
|
Venezuela
|
es_VE
|
|
Swedish
|
Sweden
|
sv_SE
|
|
Tagalog
|
Philippines
|
tl_PH
|
|
Thai
|
Thailand
|
th_TH
|
|
Thai
|
Thailand Traditional
|
th_TH_TH
|
|
Turkish
|
Turkey
|
tr_TR
|
|
Turkish (Turkey Lira)
|
Turkey
|
tr_TR_LIRA
|
|
Ukrainian
|
Ukraine
|
uk_UA
|
|
Vietnamese
|
Vietnam
|
vi_VN
|
Usually, both elements of a locale are important. For example,
the names of weekdays and months, in English, for Canada and Great
Britain are formatted identically, but dates are formatted differently.
Therefore, specifying an English language locale is insufficient.
Also, specifying only a country as the locale is insufficient. For
example, Canada has different date formats for English and French.
For information about how to set the locale in Designer, see
To specify a locale (language and country or region) for an object
.
In general, every application operates in
an environment where a locale is present. This locale is known as
the
ambient locale
. In some circumstances, an application
might operate on a system, or within an environment, where a locale is
not present. In these rare cases, the ambient locale is set to a
default of English United States (en_US). This locale is known as
a
default locale
.
Epoch
Date values and time values have an associated origin or
epoch
,
which is a moment in time from which time begins. Any date value
and any time value prior to its epoch is invalid.
The unit of value for all date functions is the number of days
since the epoch. The unit of value for all time functions is the
number of milliseconds since the epoch.
Designer defines day one for the epoch for all date functions
as Jan 1, 1900, and millisecond one for the epoch for all time functions
is midnight, 00:00:00, Greenwich Mean Time (GMT). This definition
means that negative time values can be returned to users in time
zones east of GMT.
Date formats
A
date format
is a shorthand specification of how a date
appears. It consists of various punctuation marks and symbols that
represent the formatting that the date must use. The following table
lists examples of date formats.
|
Date format
|
Example
|
|
MM/DD/YY
|
11/11/78
|
|
DD/MM/YY
|
25/07/85
|
|
MMMM DD, YYYY
|
March 10, 1964
|
The format of dates is governed by an ISO standard. Each country
or region specifies its own date formats. The four general categories
of date formats are short, medium, long, and full. The following
table contains examples of different date formats from different
locales for each of the categories.
|
Locale identifier and description
|
Date format (Category)
|
Example
|
|
en_GB
English (United Kingdom)
|
DD/MM/YY (Short)
|
08/12/92
08/04/05
|
|
fr_CA
French (Canada)
|
YY-MM-DD (Medium)
|
92-08-18
|
|
de_DE
German (Germany)
|
D. MMMM YYYY (Long)
|
17. Juni 1989
|
|
fr_FR
French (France)
|
EEEE, ' le ' D MMMM YYYY (Full)
|
Lundi, le 29 Octobre, 1990
|
Time formats
A
time format
is a shorthand specification to format a
time. It consists of punctuations, literals, and pattern symbols.
The following table lists examples of time formats.
|
Time format
|
Example
|
|
h:MM A
|
7:15 PM
|
|
HH:MM:SS
|
21:35:26
|
|
HH:MM:SS 'o''clock' A Z
|
14:20:10 o’clock PM EDT
|
Time formats are governed by an ISO standard. Each nation specifies
the form of its default, short, medium, long, and full-time formats.
The locale identifies the format of times that conform to the standards
of that nation.
The following table contains some examples of different date
formats from different locales for each of the categories.
|
Locale identifier and description
|
Time format (Category)
|
Example
|
|
en_GB
English (United Kingdom)
|
HH:MM (Short)
|
14:13
|
|
fr_CA
French (Canada)
|
HH:MM:SS (Medium)
|
12:15:50
|
|
de_DE
German (Germany)
|
HH:MM:SS z (Long)
|
14:13:13 -0400
|
|
fr_FR
French (France)
|
HH ' h ' MM Z (Full)
|
14 h 13 GMT-04:00
|
Date and time patterns
The
following symbols must be used to create date and time patterns
for date/time fields. Certain date symbols are only used in Chinese,
Japanese, and Korean locales. These symbols are also specified below.
For more information, see
Examples of date/time patterns
.
Note:
The comma (,), dash (-), colon (:), slash (/),
period (.), and space ( ) are treated as literal values and can
be included anywhere in a pattern. To include a phrase in a pattern,
delimit the text string with single quotation marks ('). For example,
'Your payment is due no later than' MM-DD-YY
can
be specified as the display pattern.
|
Date symbol
|
Description
|
Formatted value for English (USA) locale
where the locale-sensitive input value is 1/1/08 (which is January
1, 2008)
|
|
D
|
1 or 2 digit (1-31) day of the month
|
1
|
|
DD
|
Zero-padded 2 digit (01-31) day of the month
|
01
|
|
J
|
1, 2, or 3 digit (1-366) day of the year
|
1
|
|
JJJ
|
Zero-padded, three-digit (001-366) day of
the year
|
001
|
|
M
|
One- or two-digit (1-12) month of the year
|
1
|
|
MM
|
Zero-padded, two-digit (01-12) month of
the year
|
01
|
|
MMM
|
Abbreviated month name
|
Jan
|
|
MMMM
|
Full month name
|
January
|
|
E
|
One-digit (1-7) day of the week, where (1=Sunday)
|
3 (because January 1, 2008 is a Tuesday)
|
|
EEE
|
Abbreviated weekday name
|
Tue (because January 1, 2008 is a Tuesday)
|
|
EEEE
|
Full weekday name
|
Tuesday (because January 1, 2008 is a Tuesday)
|
|
YY
|
Two-digit year, where numbers less than
30 are considered to fall after the year 2000 and numbers 30 and
higher are considered to occur before 2000. For example, 00=2000,
29=2029, 30=1930, and 99=1999
|
08
|
|
YYYY
|
Four-digit year
|
2008
|
|
G
|
Era name (BC or AD)
|
AD
|
|
w
|
One-digit (0-5) week of the month, where
week 1 is the earliest set of four contiguous days ending on a Saturday
|
1
|
|
WW
|
Two-digit (01-53) ISO-8601 week of the year,
where week 1 is the week containing January 4
|
01
|
Several additional date patterns are available for specifying
date patterns in Chinese, Japanese, and Korean locales.
Japanese eras can be represented by several different symbols.
The final four era symbols provide alternative symbols to represent
Japanese eras.
|
CJK date symbol
|
Description
|
|
DDD
|
The locale’s ideographic numeric valued
day of the month
|
|
DDDD
|
The locale’s tens rule ideographic numeric
valued day of the month
|
|
YYY
|
The locale’s ideographic numeric valued
year
|
|
YYYYY
|
The locale’s tens rule ideographic numeric
valued year
|
|
g
|
The locale’s alternate era name. For the
current Japanese era, Heisei, this pattern displays the ASCII letter
H (U+48)
|
|
gg
|
The locale’s alternate era name. For the
current Japanese era, this pattern displays the ideograph that is
represented by the Unicode symbol (U+5E73)
|
|
ggg
|
The locale’s alternate era name. For the
current Japanese era, this pattern displays the ideographs that
are represented by the Unicode symbols (U+5E73 U+6210)
|
|
g
|
The locale’s alternate era name. For the
current Japanese era, this pattern displays the full width letter
H (U+FF28)
|
|
g g
|
The locale’s alternate era name. For the
current Japanese era, this pattern displays the ideograph that is
represented by the Unicode symbol (U+337B)
|
|
Time symbol
|
Description
|
Locale-sensitive input value
|
Formatted value for English (USA) locale
|
|
h
|
One- or two-digit (1-12) hour of the day
(AM/PM)
|
12:08 AM or 2:08 PM
|
12 or 2
|
|
hh
|
Zero-padded 2 digit (01-12) hour of the
day (AM/PM)
|
12:08 AM or 2:08 PM
|
12 or 02
|
|
k
|
One- or two-digit (0-11) hour of the day
(AM/PM)
|
12:08 AM or 2:08 PM
|
0 or 2
|
|
kk
|
Two-digit (00-11) hour of the day (AM/PM)
|
12:08 AM or 2:08 PM
|
00 or 02
|
|
H
|
One- or two-digit (0-23) hour of the day
|
12:08 AM or 2:08 PM
|
0 or 14
|
|
HH
|
Zero-padded, two-digit (00-23) hour of the
day
|
12:08 AM or 2:08 PM
|
00 or 14
|
|
K
|
One- or two-digit (1-24) hour of the day
|
12:08 AM or 2:08 PM
|
24 or 14
|
|
KK
|
Zero-padded, two-digit (01-24) hour of the
day
|
12:08 AM or 2:08 PM
|
24 or 14
|
|
M
|
One- or two-digit (0-59) minute of the hour
Note:
You must use this symbol with an hour symbol.
|
2:08 PM
|
8
|
|
MM
|
Zero-padded, two-digit (00-59) minute of
the hour
Note:
You must use this symbol with
an hour symbol.
|
2:08 PM
|
08
|
|
S
|
One- or two-digit (0-59) second of the minute
Note:
You must use this symbol with an hour and minute symbol.
|
2:08:09 PM
|
9
|
|
SS
|
Zero-padded, two-digit (00-59) second of
the minute
Note:
You must use this symbol with
an hour and minute symbol.
|
2:08:09 PM
|
09
|
|
FFF
|
Three- digit (000-999) thousandth of the
second
Note:
You must use this symbol with an
hour, minute, and seconds symbol.
|
2:08:09 PM
|
09
|
|
A
|
The part of the day that is from midnight
to noon (AM) or from noon to midnight (PM)
|
2:08:09 PM
|
PM
|
|
z
|
ISO-8601 time-zone format (for example,
Z,
+0500,
-0030, -01, +0100)
Note:
You must use this symbol
with an hour symbol.
|
2:08:09 PM
|
-0400
|
|
zz
|
Alternative ISO-8601 time-zone format (for
example,
Z,
+05:00, -00:30, -01, +01:00)
Note:
You must use this symbol with an hour symbol.
|
2:08:09 PM
|
-04:00
|
|
Z
|
Abbreviated time-zone name (for example,
GMT, GMT+05:00, GMT-00:30, EST, PDT)
Note:
You
must use this symbol with an hour symbol.
|
2:08:09 PM
|
EDT
|
Reserved symbols
The following symbols have special meanings and
cannot be used as literal text.
|
Symbol
|
Description
|
|
?
|
When submitted, the symbol matches any one
character. When merged for display, it becomes a space.
|
|
*
|
When submitted, the symbol matches 0 or
Unicode white space characters. When merged for display, it becomes
a space.
|
|
+
|
When submitted, the symbol matches one or
more Unicode white space characters. When merged for display, it
becomes a space.
|
Complex field patterns
In
addition to defining simple patterns for date/time fields, numeric
fields, and text fields, you can define a locale-specific pattern
or handle variable patterns.
Locale-specific patterns
If you want to force a locale on a pattern, regardless
of the locale that has already been assigned to an object, you can
define a locale-specific pattern. The syntax of a locale-specific
pattern is defined as follows:
category_name(locale_name){pattern}
where
-
category_name
can be
date
,
time
,
num
,
or
text
.
-
locale_name
is identified by a language
and/or country or region code, as defined in RFC 1766 (Tags for
the Identification of Languages, 1995).
-
pattern
is the simple pattern for processing
values.
For example, to force a date/time field to translate a date into
the French language according to France’s country code, you would
define the pattern as follows:
date(fr_FR){DD MMMM, YYYY}
Variable patterns
In cases where the user input or bound data is available
in more than one format (for example, telephone numbers may or may
not have a three-digit area code), you can define a pattern that
accounts for the differences. The syntax for defining a number of
acceptable patterns is as follows:
category_name{pattern}|category_name{pattern}|category_name{pattern}
where each pattern is separated by a vertical bar (|). You can
specify an unlimited number of patterns. For example, the following
construct handles two different text patterns:
text{999*9999}|text{999*999*9999}
To set a default font for values in new forms
-
On the Tools menu, select Options.
-
Click Default Fonts.
-
Under Default Value Font Properties For New Forms, select
Typeface, Size, and Style options. as needed.
To set a default font for values in an existing form
-
Click File > Form Properties.
-
Click Default Fonts.
-
Under Default Value Font Properties, select Typeface, Size,
and Style options. as needed.
|
|
|
