Date/time parsing is evidently one of the most relevant aspects of DateParser. In application of the defining FlexibleParser ideas and even my usual approach when facing these developments, all the associated functionalities are very user-friendly and can gracefully deal with a wide variety of different input formats.

The main parsing aspects of DateParser are eminently defined according to the following main classes:

• CustomDateTimeFormat and StandardDateTimeFormat. They emulate (StandardDateTimeFormat) and extend (CustomDateTimeFormat) the date/time input formats supported by the .NET Framework.
  The StandardDateTimeFormat/CustomDateTimeFormat distinction is very relevant for most of the parsing methods, which are stored inside the files in the Dates/Parse folder. The bigger and more relevant code is logically the one dealing with the custom-made alternative which is stored in the Custom subfolder.
• DateP is the main class dealing with all the parsing aspects. Its main purpose is to somehow emulate the in-built .NET date/time type (DateTime/Date) by mostly focusing on the parsing methods (e.g., Parse or ParseExact); it extends the default .NET support and accounts for time zones, which represent the other main DateParser resource.
  DateP includes various public properties whose values are fully synchronised and immediately updated. The most relevant public properties of DateP are the following:
  • Value (DateTime/Date) ensures full compatibility of DateP instances with the default .NET type.
  • TimeZoneOffset (Offset) allows DateP to support the other relevant aspect of DateParser: time zones.
  • Various properties referring to the constituent elements of dates/times. They are meant to further improve the UnitP user-friendliness and to enable punctual variations which aren't supported by the default .NET type (e.g., modifying the day of the week).