For fields of type FT_ABSOLUTE_TIME, have the "display" value be one of

ABSOLUTE_TIME_LOCAL or ABSOLUTE_TIME_UTC, indicating whether to display
the date/time in local time or UTC. (int)ABSOLUTE_TIME_LOCAL ==
(int)BASE_NONE, so there's no source or binary compatiblity issue,
although we might want to eliminate BASE_NONE at some point and have the
BASE_ values used with integral types start at 0, so that you can't
specify BASE_NONE for an integral field.

svn path=/trunk/; revision=31319

1 files changed, 27 insertions, 10 deletions

diff --git a/doc/README.developer b/doc/README.developer
index da73e951f4..730bfa8ad7 100644
--- a/doc/README.developer
+++ b/doc/README.developer
@@ -1088,9 +1088,18 @@ FIELDTYPE	FT_NONE, FT_BOOLEAN, FT_UINT8, FT_UINT16, FT_UINT24,
 		FT_RELATIVE_TIME, FT_STRING, FT_STRINGZ, FT_EBCDIC,
 		FT_UINT_STRING,	FT_ETHER, FT_BYTES, FT_UINT_BYTES, FT_IPv4,
 		FT_IPv6, FT_IPXNET, FT_FRAMENUM, FT_PROTOCOL, FT_GUID, FT_OID
-FIELDBASE	BASE_NONE, BASE_DEC, BASE_HEX, BASE_OCT, BASE_DEC_HEX,
-		BASE_HEX_DEC, or BASE_CUSTOM, possibly ORed with
-		BASE_RANGE_STRING
+FIELDBASE	For FT_UINT{8,16,24,32} and FT_INT{8,16,24,32):
+
+		BASE_DEC, BASE_HEX, BASE_OCT, BASE_DEC_HEX, BASE_HEX_DEC,
+		or BASE_CUSTOM, possibly ORed with BASE_RANGE_STRING
+
+		For FT_ABSOLUTE_TIME:
+
+		ABSOLUTE_TIME_LOCAL or ABSOLUTE_TIME_UTC
+
+		For all other types:
+
+		BASE_NONE
 FIELDCONVERT	VALS(x), RVALS(x), TFS(x), NULL
 BITMASK		Usually 0x0 unless using the TFS(x) field conversion.
 FIELDDESCR	A brief description of the field, or NULL.
@@ -1688,10 +1697,13 @@ signed integers; the number on the end represent how many bits are used
 to represent the number.
 
 Some constraints are imposed on the header fields depending on the type
-(e.g. FT_BYTES) of the field. Non integral types (e.g. types that are _not_
-FT_INT* and FT_UINT*) must use 'BASE_NONE', NULL, 0x0' as values for the
-'display', 'strings', 'bitmask' fields. The reason is simply that the type
-itself implictly defines the nature of 'display', 'strings', 'bitmask'.
+(e.g. FT_BYTES) of the field.  Fields of type FT_ABSOLUTE_TIME must use
+'ABSOLUTE_TIME_{LOCAL,UTC}, NULL, 0x0' as values for the 'display,
+'strings', and 'bitmask' fields, and all other non-integral types (i.e..
+types that are _not_ FT_INT* and FT_UINT*) must use 'BASE_NONE, NULL, 0x0'
+as values for the 'display', 'strings', 'bitmask' fields. The reason is
+simply that the type itself implictly defines the nature of 'display',
+'strings', 'bitmask'.
 
 display
 -------
@@ -1730,9 +1742,14 @@ With integers this is not needed since the type of integer itself
 (FT_UINT8, FT_UINT16, FT_UINT24, FT_UINT32, etc.) tells the proto_tree how
 wide the parent bitfield is.
 
-Additionally, BASE_NONE is used for 'display' as a NULL-value. That is,
-for non-integers and non-bitfield FT_BOOLEANs, you'll want to use BASE_NONE
-in the 'display' field.  You may not use BASE_NONE for integers.
+For FT_ABSOLUTE_TIME fields, 'display' is used to indicate whether the
+time is to be displayed as a time in the time zone for the machine on
+which Wireshark/TShark is running or as UTC.
+
+Additionally, BASE_NONE is used for 'display' as a NULL-value. That is, for 
+for non-integers other than FT_ABSOLUTE_TIME fields, and non-bitfield
+FT_BOOLEANs, you'll want to use BASE_NONE in the 'display' field.  You may
+not use BASE_NONE for integers.
 
 It is possible that in the future we will record the endianness of
 integers. If so, it is likely that we'll use a bitmask on the display field