Handling text in Noda Time

There are two options for text handling in Noda Time. For some elements of formatting, you can follow the "normal" approach from the .NET Base Class Library (BCL) - in particular, most of the core Noda Time types implements IFormattable. However, no parsing support is provided in this way. (It used to be, but the whole approach is so convoluted that documenting it accurately proved too great an overhead.)

The preferred approach is to use the "pattern" classes such as LocalDatePattern and so forth. This leads to clearer, more robust code, and performs better. The formatting support present in the BCL style is mostly present to work well with compound format strings, where you may wish to mix several values of different types in a single formatting call.

All the types responsible for text in Noda Time are in the NodaTime.Text namespace.

The pattern-based API

A pattern is an object capable of parsing from text to a specific type, and formatting a value to text. Parsing and formatting don't take any other options: the pattern knows everything about how to map between the value and text. In particular, internationalization is handled by having the pattern hold a CultureInfo.

Whereas using the BCL approach the format information has to be specified on every call, using the pattern approach the format information is fixed for any particular pattern. Convenience methods are provided to create new pattern instances based on existing ones but with different internationalization information or other options.

Each core Noda type has its own pattern type such as OffsetPattern. All these patterns implement the IPattern<T> interface, which has simple Format and Parse methods taking just the value and text respectively. The result of Parse is a ParseResult<T> which encapsulates both success and failure results.

The BCL-based API

Most of the core Noda Time types (LocalDateTime, Instant etc) provide methods with the following signatures:

Pattern text

Each type has its own separate pattern text documentation. The available patterns are as consistent as possible within reason, but documenting each separately avoids confusion with some field specifiers being available for some types but not others.

Note that at present, ZonedDateTime, OffsetDateTime and Duration do not support any form of parsing or user-specified formatting.

Custom patterns

All custom patterns support the following characters:

Character Meaning Example
% Escape to force a single-character custom pattern to be treated as such. %H => 5
' Open and close a text literal, which can include double quotes. HH'H'mm'm' => 07H30M
" Open and close a text literal, which can include single quotes. HH"'"mm => 07'30
\ Escapes the following character. HH\'mm => 07'30

Additionally:

Any characters within a custom format which don't have a specific meaning are treated as text literals (when parsing, they must be matched exactly; when formatting they are reproduced exactly). This is supported mostly for the sake of compatibility. We strongly recommend that you quote any text literals, to avoid nasty surprises if extra characters take on special meanings in later versions.