The contents in this website aren't being updated anymore. For more information, go to https://varocarbas.com/.
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).