... Three Standard [Types] are available for encoding dates and times:
* a date on its own
* a time on its own
* a combined date with a time
Fudge date/time encoding aims to support most language implementations by supporting optional timezone information, and from year to nanosecond precision.
{anchor:Date}
h2. Date
A date is encoded as a 4-byte value containing a year, month, and day packed as:
||Bits ||Meaning ||
|31 - 9|Year (2s complement to allow negative values for BC)|
|8 - 5|Month of year (1..12, or 0 to omit)|
|4 - 0|Day of month (1..31, or 0 to omit)|
The month and day, or just the day can be omitted by using the value 0. Values of 13 or higher are not currently valid in the month field. For example:
||Date || Coded values || Packed value ||
|31 January 2010| 2010, {color:green}1{color}, {color:blue}31{color} | 0000 0000 0000 1111 1011 010{color:green}0 001{color}{color:blue}1 1111{color} |
|August 2000| 2000, {color:green}8{color}, {color:blue}0{color} | 0000 0000 0000 1111 1010 000{color:green}1 000{color}{color:blue}0 0000{color} |
| 3,000,000 BC | -3000000, {color:green}0{color}, {color:blue}0{color} | 1010 0100 0111 0010 1000 000{color:green}0 000{color}{color:blue}0 0000{color} |
Note the colors are to show where the fields start/end in the packed value - they have no other meaning. Clearly some values are not valid dates and should not be used. The behaviour of an invalid date value is undefined. A system may either ignore any attempt to validate it and pass the value unchanged within a message, or if there is validation as part of conversion to a native language type trigger an appropriate error.
{anchor:Time}
h2. Time
|
A time (time of day) is encoded as 8 bytes, holding data as follows:
||Bits ||Meaning ||Encoding ||
|
| 63 - 56 | Timezone offset | Offset from UTC in 15-minute intervals. Signed 8-bit integer. Special value -128 means no timezone information |
|
| 55 | Unused | |
|
| 545 - 52 | Accuracy | Enumerated value - see below |
|
| 51 - 32 | Seconds since midnight | Unsigned 20-bit integer |
|
| 51 - 49 | Unused | Set to zero |
| 48 - 32 | Seconds since midnight | Unsigned 17-bit integer* |
| 31 - 29 | Unused | Set to zero |
|
| 31 29 - 0 | Nanoseconds since the start of the second | Unsigned 32-bit integer 30-bit integer* |
|
|
* The valid ranges for seconds since midnight and nanoseconds since start of the second are encoded as unsigned values. They are aligned to 32 bit boundaries so an implementation may set the most significant bits to 0 and work with 32-bit signed integers internally if preferred.
|
Timezone examples:
| GMT | Greenwich Mean Time | London | UTC+0H | 0 |
|
... | CET | Central European Time | Frankfurt | UTC+1H | 4 |
| PST | Pacific Standard Time | LA | UTC-8H | -32 |
| ACST | Australian Central Standard Time | Darwin | UTC+9:30H | 38 |
If further details of the Timezone are required, beyond the offset, they cannot be represented within this type. Any such information is likely to be specific to an application's requirement for processing date/time information and so should be sent as one or more separate fields in an application defined manner.
|
Accuracy is an enumeration (ordered to follow the English semantics of "greater" precision meaning smaller):
|
* 0 = Hour Millennium
|
* 1 = Minute Century
|
* 2 = Second Year
|
* 3 = Millisecond Month
|
* 4 = Microsecond Day
|
* 5 = Nanosecond Hour
|
* 6 = Minute
* 7 = Second
* 8 = Millisecond
* 9 = Microsecond
* 10 = Nanosecond
|
|
Values of 0 through 4 are only valid for DateTime (see below).
|
{anchor:DateTime}
h2. Combined date and time
|
The combined date and time value is a 12-byte sequence - the 4-byte date as encoded above, followed by the 8-byte time as encoded above. Adding a time implies a minimum precision of an hour, and so the month and day fields of the date may not be 0.
|
