@webority-technologies/mobile-core 0.0.3 → 0.0.5

package/lib/typescript/commonjs/formatters/dateMath.d.ts

@@ -0,0 +1,79 @@
+import type { DateInput } from './date';
+/**
+ * Whether two values fall on the same calendar day in the device's local
+ * timezone. Invalid input on either side returns false rather than throwing.
+ */
+export declare const isSameDay: (a: DateInput, b: DateInput) => boolean;
+/** `a` is strictly before `b`. Invalid input on either side returns false. */
+export declare const isDateBefore: (a: DateInput, b: DateInput) => boolean;
+/** `a` is strictly after `b`. Invalid input on either side returns false. */
+export declare const isDateAfter: (a: DateInput, b: DateInput) => boolean;
+/**
+ * `a - b` in milliseconds, matching dayjs's `a.diff(b)` sign convention
+ * (positive when `a` is later than `b`). Returns `NaN` if either side fails
+ * to parse, the same way subtracting two invalid dayjs objects would.
+ */
+export declare const diffMs: (a: DateInput, b: DateInput) => number;
+/**
+ * Midnight of the given date, in the device's local timezone. Returns null
+ * for unparseable input.
+ */
+export declare const startOfDay: (value: DateInput) => Date | null;
+/**
+ * Adds (or, with a negative count, subtracts) whole calendar days in the
+ * device's local timezone. Returns null for unparseable input.
+ */
+export declare const addDays: (value: DateInput, count: number) => Date | null;
+/**
+ * Small dayjs/moment-style token formatter — YYYY/YY, MMMM/MMM/MM/M,
+ * DD/D, dddd/ddd, HH/H (24h), hh/h (12h), mm/m, ss/s, A/a (upper/lower AM/PM).
+ * Everything else in the pattern (spaces, commas, colons) passes through
+ * literally. Hand-rolled rather than a dependency because this fleet's date
+ * formatting needs are a small, closed token set, not general i18n — for
+ * genuinely locale-aware output, `formatDate`/`formatTime` (Intl-backed, in
+ * `./date`) are the ones to reach for; this is for matching an exact
+ * existing pattern (a legacy display string, an API's expected shape).
+ *
+ * `utc: true` reads every field from the UTC calendar/clock instead of the
+ * device's local one — see `formatDateDDMMMYYYY`'s note on why this isn't
+ * cosmetic.
+ */
+export declare const formatDatePattern: (value: DateInput, pattern: string, options?: {
+    utc?: boolean;
+}) => string;
+/**
+ * `DD MMM, YYYY` — zero-padded day, short month, comma, year (e.g.
+ * `05 Sep, 2025`). A specific legacy pattern some apps already display,
+ * not the fleet's own product convention: `formatDate` (the Intl `style`-based
+ * formatter in `./date`) is the one to reach for in new code. This exists so
+ * an app already showing this exact pattern can move off a date library
+ * without a visible change.
+ *
+ * `utc: true` reads the calendar day from the UTC fields instead of the
+ * device's local ones — matching `dayjs.utc(x).format(...)`, not
+ * `dayjs(x).format(...)`. The two disagree whenever local time has crossed a
+ * day boundary UTC hasn't yet (or vice versa), so this is not a cosmetic
+ * option; pass it only to match a call site that was genuinely UTC-explicit.
+ */
+export declare const formatDateDDMMMYYYY: (value: DateInput, options?: {
+    utc?: boolean;
+}) => string;
+/** `YYYY-MM-DD`, in the device's local timezone. */
+export declare const formatDateISO: (value: DateInput) => string;
+/**
+ * `hh:mm A` in the device's local timezone — zero-padded 12-hour clock,
+ * uppercase AM/PM (e.g. `09:30 PM`).
+ */
+export declare const formatTime12h: (value: DateInput) => string;
+/**
+ * `hh:mm a` (zero-padded 12-hour, lowercase am/pm) of the given instant as
+ * seen in `ianaTimeZone` (e.g. `Asia/Kolkata`) — not the device's own
+ * timezone. Reads the hour/minute/period through `Intl.DateTimeFormat`'s
+ * `formatToParts` rather than its assembled string, because the assembled
+ * string's spacing before AM/PM varies by JS engine (some insert a narrow
+ * no-break space, U+202F, instead of a plain space) and isn't reliably
+ * zero-padded either. Throws if `ianaTimeZone` isn't a timezone Intl
+ * recognises — the same failure mode as handing dayjs.tz() a bad zone name.
+ */
+export declare const formatTimeInZone: (value: DateInput, ianaTimeZone: string) => string;
+//# sourceMappingURL=dateMath.d.ts.map

package/lib/typescript/commonjs/formatters/index.d.ts

@@ -2,6 +2,7 @@ export type { FormatCurrencyOptions } from './currency';
 export { formatCurrency } from './currency';
 export type { DateInput, DateStyle, TimeStyle } from './date';
 export { formatDate, formatDateTime, formatRelativeTime, formatTime } from './date';
+export { addDays, diffMs, formatDateDDMMMYYYY, formatDateISO, formatDatePattern, formatTime12h, formatTimeInZone, isDateAfter, isDateBefore, isSameDay, startOfDay } from './dateMath';
 export { getInitials } from './initials';
 export { formatCompactNumber, formatNumber, formatPercent } from './number';
 export type { FormatPhoneOptions, PhoneCountry, PhoneNumber } from './phone';

package/lib/typescript/commonjs/formatters/phone.d.ts

@@ -1,15 +1,21 @@
 /**
- * Real cross-country validation, re-exported rather than reimplemented.
- * formatPhone/normalizePhone/detectPhoneCountry below are a fast, dependency-
- * light DISPLAY formatter for a fixed set of countries; they are not a
- * validator. Real phone number plans have country-specific area-code and
- * mobile-prefix rules that only a maintained metadata table gets right -
- * hand-rolling that risks silently-wrong validation for a country nobody
- * tests against. Both live here so consumers get one phone module, not two.
+ * The bare 'libphonenumber-js' entry point actually resolves to the library's
+ * OWN slimmed-down min/ metadata internally, not its full data - './max' is
+ * the variant with complete per-country metadata. Since the reason this
+ * module exists is validation and formatting accuracy, the more accurate
+ * variant wins throughout this file, not just for validation.
  */
-export type { PhoneNumber } from 'libphonenumber-js';
-export { isValidPhoneNumber, parsePhoneNumber, parsePhoneNumberFromString } from 'libphonenumber-js';
-export type PhoneCountry = 'IN' | 'US' | 'GB' | 'AE' | 'AU' | 'SG' | 'CA';
+import { type CountryCode } from 'libphonenumber-js/max';
+export type { PhoneNumber } from 'libphonenumber-js/max';
+export { isValidPhoneNumber, parsePhoneNumber, parsePhoneNumberFromString } from 'libphonenumber-js/max';
+/**
+ * Re-exported under our own name rather than importing CountryCode directly
+ * everywhere, so a future need to diverge (or re-narrow) has one place to do
+ * it. Every ISO 3166-1 alpha-2 code libphonenumber-js recognises - formatPhone
+ * and detectPhoneCountry below are genuinely correct for all of them, not a
+ * curated subset.
+ */
+export type PhoneCountry = CountryCode;
 export interface FormatPhoneOptions {
     defaultCountryCode?: string;
     country?: PhoneCountry;
@@ -22,17 +28,22 @@ export declare const normalizePhone: (input: string) => string;
 /**
  * Detect the country of a phone number: from its own `+` country code when
  * present, otherwise from `defaultCountryCode`. Returns null when neither
- * carries a recognised calling code.
+ * parses to a recognised country.
  */
 export declare const detectPhoneCountry: (input: string, defaultCountryCode?: string) => PhoneCountry | null;
 /**
- * Format a phone number for human display.
+ * Format a phone number for human display, via libphonenumber-js's own
+ * per-country formatting rather than a hand-rolled grouping table - correct
+ * for every country it recognises, not a curated subset.
  *
- * - Indian mobile (10 digits) → `XXXXX XXXXX`
- * - With `+91` country code → `+91 XXXXX XXXXX`
- * - A number that already carries a recognised country code is grouped for
- *   that country regardless of `defaultCountryCode`.
- * - Other inputs are returned as `+CC NNNN NNNN…` best-effort grouping.
+ * - A number that already carries a `+` country code formats for that country.
+ * - A bare national number formats for `options.country` when given, else for
+ *   the country implied by `defaultCountryCode` (default `+91`).
+ * - `includeCountryCode` controls international vs national format; defaults
+ *   to international whenever the country was detected rather than passed in
+ *   explicitly as `options.country`, and to national when it was.
+ * - Input libphonenumber-js can't parse into a valid number for the resolved
+ *   country falls back to a best-effort `+CC NNNN NNNN…` digit grouping.
  */
 export declare function formatPhone(input: string, defaultCountryCode?: string): string;
 export declare function formatPhone(input: string, options?: FormatPhoneOptions): string;

package/lib/typescript/commonjs/index.d.ts

@@ -29,7 +29,7 @@ export { getConfig, getConfigValue, resetConfig, setConfig } from './config';
 export type { DeepLinkConfig, DeepLinkRoute, ParsedLink } from './deepLink';
 export { DeepLink, parseDeepLink, useDeepLink } from './deepLink';
 export type { DateInput, DateStyle, FormatCurrencyOptions, FormatPhoneOptions, PhoneCountry, PhoneNumber, TimeStyle } from './formatters';
-export { detectPhoneCountry, formatCompactNumber, formatCurrency, formatDate, formatDateTime, formatNumber, formatPercent, formatPhone, formatRelativeTime, formatTime, getInitials, isValidPhoneNumber, normalizePhone, parsePhoneNumber, parsePhoneNumberFromString } from './formatters';
+export { addDays, detectPhoneCountry, diffMs, formatCompactNumber, formatCurrency, formatDate, formatDateDDMMMYYYY, formatDateISO, formatDatePattern, formatDateTime, formatNumber, formatPercent, formatPhone, formatRelativeTime, formatTime, formatTime12h, formatTimeInZone, getInitials, isDateAfter, isDateBefore, isSameDay, isValidPhoneNumber, normalizePhone, parsePhoneNumber, parsePhoneNumberFromString, startOfDay } from './formatters';
 export type { InitConfig } from './initSDK';
 export { initWebority } from './initSDK';
 export type { AuthActions } from './initUserAuth';

package/lib/typescript/module/formatters/dateMath.d.ts

@@ -0,0 +1,79 @@
+import type { DateInput } from './date.js';
+/**
+ * Whether two values fall on the same calendar day in the device's local
+ * timezone. Invalid input on either side returns false rather than throwing.
+ */
+export declare const isSameDay: (a: DateInput, b: DateInput) => boolean;
+/** `a` is strictly before `b`. Invalid input on either side returns false. */
+export declare const isDateBefore: (a: DateInput, b: DateInput) => boolean;
+/** `a` is strictly after `b`. Invalid input on either side returns false. */
+export declare const isDateAfter: (a: DateInput, b: DateInput) => boolean;
+/**
+ * `a - b` in milliseconds, matching dayjs's `a.diff(b)` sign convention
+ * (positive when `a` is later than `b`). Returns `NaN` if either side fails
+ * to parse, the same way subtracting two invalid dayjs objects would.
+ */
+export declare const diffMs: (a: DateInput, b: DateInput) => number;
+/**
+ * Midnight of the given date, in the device's local timezone. Returns null
+ * for unparseable input.
+ */
+export declare const startOfDay: (value: DateInput) => Date | null;
+/**
+ * Adds (or, with a negative count, subtracts) whole calendar days in the
+ * device's local timezone. Returns null for unparseable input.
+ */
+export declare const addDays: (value: DateInput, count: number) => Date | null;
+/**
+ * Small dayjs/moment-style token formatter — YYYY/YY, MMMM/MMM/MM/M,
+ * DD/D, dddd/ddd, HH/H (24h), hh/h (12h), mm/m, ss/s, A/a (upper/lower AM/PM).
+ * Everything else in the pattern (spaces, commas, colons) passes through
+ * literally. Hand-rolled rather than a dependency because this fleet's date
+ * formatting needs are a small, closed token set, not general i18n — for
+ * genuinely locale-aware output, `formatDate`/`formatTime` (Intl-backed, in
+ * `./date`) are the ones to reach for; this is for matching an exact
+ * existing pattern (a legacy display string, an API's expected shape).
+ *
+ * `utc: true` reads every field from the UTC calendar/clock instead of the
+ * device's local one — see `formatDateDDMMMYYYY`'s note on why this isn't
+ * cosmetic.
+ */
+export declare const formatDatePattern: (value: DateInput, pattern: string, options?: {
+    utc?: boolean;
+}) => string;
+/**
+ * `DD MMM, YYYY` — zero-padded day, short month, comma, year (e.g.
+ * `05 Sep, 2025`). A specific legacy pattern some apps already display,
+ * not the fleet's own product convention: `formatDate` (the Intl `style`-based
+ * formatter in `./date`) is the one to reach for in new code. This exists so
+ * an app already showing this exact pattern can move off a date library
+ * without a visible change.
+ *
+ * `utc: true` reads the calendar day from the UTC fields instead of the
+ * device's local ones — matching `dayjs.utc(x).format(...)`, not
+ * `dayjs(x).format(...)`. The two disagree whenever local time has crossed a
+ * day boundary UTC hasn't yet (or vice versa), so this is not a cosmetic
+ * option; pass it only to match a call site that was genuinely UTC-explicit.
+ */
+export declare const formatDateDDMMMYYYY: (value: DateInput, options?: {
+    utc?: boolean;
+}) => string;
+/** `YYYY-MM-DD`, in the device's local timezone. */
+export declare const formatDateISO: (value: DateInput) => string;
+/**
+ * `hh:mm A` in the device's local timezone — zero-padded 12-hour clock,
+ * uppercase AM/PM (e.g. `09:30 PM`).
+ */
+export declare const formatTime12h: (value: DateInput) => string;
+/**
+ * `hh:mm a` (zero-padded 12-hour, lowercase am/pm) of the given instant as
+ * seen in `ianaTimeZone` (e.g. `Asia/Kolkata`) — not the device's own
+ * timezone. Reads the hour/minute/period through `Intl.DateTimeFormat`'s
+ * `formatToParts` rather than its assembled string, because the assembled
+ * string's spacing before AM/PM varies by JS engine (some insert a narrow
+ * no-break space, U+202F, instead of a plain space) and isn't reliably
+ * zero-padded either. Throws if `ianaTimeZone` isn't a timezone Intl
+ * recognises — the same failure mode as handing dayjs.tz() a bad zone name.
+ */
+export declare const formatTimeInZone: (value: DateInput, ianaTimeZone: string) => string;
+//# sourceMappingURL=dateMath.d.ts.map

package/lib/typescript/module/formatters/index.d.ts

@@ -2,6 +2,7 @@ export type { FormatCurrencyOptions } from './currency.js';
 export { formatCurrency } from './currency.js';
 export type { DateInput, DateStyle, TimeStyle } from './date.js';
 export { formatDate, formatDateTime, formatRelativeTime, formatTime } from './date.js';
+export { addDays, diffMs, formatDateDDMMMYYYY, formatDateISO, formatDatePattern, formatTime12h, formatTimeInZone, isDateAfter, isDateBefore, isSameDay, startOfDay } from './dateMath.js';
 export { getInitials } from './initials.js';
 export { formatCompactNumber, formatNumber, formatPercent } from './number.js';
 export type { FormatPhoneOptions, PhoneCountry, PhoneNumber } from './phone.js';

package/lib/typescript/module/formatters/phone.d.ts

@@ -1,15 +1,21 @@
 /**
- * Real cross-country validation, re-exported rather than reimplemented.
- * formatPhone/normalizePhone/detectPhoneCountry below are a fast, dependency-
- * light DISPLAY formatter for a fixed set of countries; they are not a
- * validator. Real phone number plans have country-specific area-code and
- * mobile-prefix rules that only a maintained metadata table gets right -
- * hand-rolling that risks silently-wrong validation for a country nobody
- * tests against. Both live here so consumers get one phone module, not two.
+ * The bare 'libphonenumber-js' entry point actually resolves to the library's
+ * OWN slimmed-down min/ metadata internally, not its full data - './max' is
+ * the variant with complete per-country metadata. Since the reason this
+ * module exists is validation and formatting accuracy, the more accurate
+ * variant wins throughout this file, not just for validation.
  */
-export type { PhoneNumber } from 'libphonenumber-js';
-export { isValidPhoneNumber, parsePhoneNumber, parsePhoneNumberFromString } from 'libphonenumber-js';
-export type PhoneCountry = 'IN' | 'US' | 'GB' | 'AE' | 'AU' | 'SG' | 'CA';
+import { type CountryCode } from 'libphonenumber-js/max';
+export type { PhoneNumber } from 'libphonenumber-js/max';
+export { isValidPhoneNumber, parsePhoneNumber, parsePhoneNumberFromString } from 'libphonenumber-js/max';
+/**
+ * Re-exported under our own name rather than importing CountryCode directly
+ * everywhere, so a future need to diverge (or re-narrow) has one place to do
+ * it. Every ISO 3166-1 alpha-2 code libphonenumber-js recognises - formatPhone
+ * and detectPhoneCountry below are genuinely correct for all of them, not a
+ * curated subset.
+ */
+export type PhoneCountry = CountryCode;
 export interface FormatPhoneOptions {
     defaultCountryCode?: string;
     country?: PhoneCountry;
@@ -22,17 +28,22 @@ export declare const normalizePhone: (input: string) => string;
 /**
  * Detect the country of a phone number: from its own `+` country code when
  * present, otherwise from `defaultCountryCode`. Returns null when neither
- * carries a recognised calling code.
+ * parses to a recognised country.
  */
 export declare const detectPhoneCountry: (input: string, defaultCountryCode?: string) => PhoneCountry | null;
 /**
- * Format a phone number for human display.
+ * Format a phone number for human display, via libphonenumber-js's own
+ * per-country formatting rather than a hand-rolled grouping table - correct
+ * for every country it recognises, not a curated subset.
  *
- * - Indian mobile (10 digits) → `XXXXX XXXXX`
- * - With `+91` country code → `+91 XXXXX XXXXX`
- * - A number that already carries a recognised country code is grouped for
- *   that country regardless of `defaultCountryCode`.
- * - Other inputs are returned as `+CC NNNN NNNN…` best-effort grouping.
+ * - A number that already carries a `+` country code formats for that country.
+ * - A bare national number formats for `options.country` when given, else for
+ *   the country implied by `defaultCountryCode` (default `+91`).
+ * - `includeCountryCode` controls international vs national format; defaults
+ *   to international whenever the country was detected rather than passed in
+ *   explicitly as `options.country`, and to national when it was.
+ * - Input libphonenumber-js can't parse into a valid number for the resolved
+ *   country falls back to a best-effort `+CC NNNN NNNN…` digit grouping.
  */
 export declare function formatPhone(input: string, defaultCountryCode?: string): string;
 export declare function formatPhone(input: string, options?: FormatPhoneOptions): string;

package/lib/typescript/module/index.d.ts

@@ -29,7 +29,7 @@ export { getConfig, getConfigValue, resetConfig, setConfig } from './config/inde
 export type { DeepLinkConfig, DeepLinkRoute, ParsedLink } from './deepLink/index.js';
 export { DeepLink, parseDeepLink, useDeepLink } from './deepLink/index.js';
 export type { DateInput, DateStyle, FormatCurrencyOptions, FormatPhoneOptions, PhoneCountry, PhoneNumber, TimeStyle } from './formatters/index.js';
-export { detectPhoneCountry, formatCompactNumber, formatCurrency, formatDate, formatDateTime, formatNumber, formatPercent, formatPhone, formatRelativeTime, formatTime, getInitials, isValidPhoneNumber, normalizePhone, parsePhoneNumber, parsePhoneNumberFromString } from './formatters/index.js';
+export { addDays, detectPhoneCountry, diffMs, formatCompactNumber, formatCurrency, formatDate, formatDateDDMMMYYYY, formatDateISO, formatDatePattern, formatDateTime, formatNumber, formatPercent, formatPhone, formatRelativeTime, formatTime, formatTime12h, formatTimeInZone, getInitials, isDateAfter, isDateBefore, isSameDay, isValidPhoneNumber, normalizePhone, parsePhoneNumber, parsePhoneNumberFromString, startOfDay } from './formatters/index.js';
 export type { InitConfig } from './initSDK.js';
 export { initWebority } from './initSDK.js';
 export type { AuthActions } from './initUserAuth.js';

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@webority-technologies/mobile-core",
-  "version": "0.0.3",
+  "version": "0.0.5",
   "description": "Platform layer for Webority React Native apps: HTTP clients, auth/token storage, config, logging, formatters, validators, network status, permissions, storage and version checks. No UI.",
   "keywords": [
     "react-native",