This is a very simplistic implementation of a parser to convert any single culture's short date pattern into a Date object (UTC or local). There are much better libraries to provide multi-culture handling of dates to consider implementing IDataTypeParser. Short date pattern has 3 groups of digits, separated by a non-digit delimiter. The culture determines which group is year, month, or day. To setup, you must supply both the order of ymd, and the separator character. Therefore, you must register one of these for EACH culture that uses the pattern.

Hierarchy (view full)

Constructors

Properties

badDataMessage: "Expecting a date" = 'Expecting a date'
invalidDateMessage: "Not a valid date" = 'Not a valid date'

For when you have all numbers for y/m/d, but put together to form a date and its not a legal date. For example, m=13, d=0, or the day is after the last day of the month.

Accessors

  • get supportedCultures(): string[]
  • All cultureIds that support the order and separator. Note that if there is language-specific culture and one that is not language specific but has the same local, you can define just the one for the local because the DataTypeParser service will search both language specific and language agnostic when the CultureService is setup with fallbacks.

    Returns string[]

  • get utc(): boolean
  • When true, the Date object is UTC. When false, it is local. Assigned through the constructor. Defaults to true (UTC on). This is not part of the options object because its independent of cultureinfo rules. Its a usage decision by the user.

    Returns boolean

Methods

  • If the user needs to abandon this instance, they should use this to clean up active resources (like timers) and to release memory that would stall the garbage collector from disposing this object. It should assign any object reference to undefined as a strong indicator that the object has been disposed.

    Returns void

  • Changes the text if needed before parsing. Usually removes unwanted characters like trimming whitespace, but it could try to fix the data to closely resemble the desired text pattern that will be parsed by parseCleanedText. When it comes to strings as the native data type, it can rework the text to be the pattern expected for storage. For example, you might store a US phone number in this pattern: [3 digits]-[3 digits]-[4 digits]. The user may enter it in another familiar pattern like "(413) 555-0521" or "413 555 0520". This would clean it up to the desired pattern of "413-555-0521".

    Parameters

    • text: string
    • dataTypeLookupKey: string
    • cultureId: string

    Returns string

  • In addition to matching by dataTypeLookupKey, it also requires the text to match a regular expression. The expression reflects the one or very few patterns that parse() expects to work with. By the time parse() is called, it knows the expression has the pattern and can simply work within the regexp results.

    Parameters

    • dataTypeLookupKey: string
    • cultureId: string
    • text: string

    Returns boolean

Generated using TypeDoc v0.25.12