dately 3.3.0__cp313-cp313-win_amd64.whl
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- dately/__init__.py +282 -0
- dately/_api.py +85 -0
- dately/_connect.py +466 -0
- dately/_datetime_scan.py +1664 -0
- dately/_holiday.py +391 -0
- dately/_log.py +51 -0
- dately/_mskutils.py +156 -0
- dately/_proxy.py +86 -0
- dately/_sysutils.py +239 -0
- dately/_temporal_scan.py +2581 -0
- dately/_timeutils.py +449 -0
- dately/_timezone.py +348 -0
- dately/_utils.py +139 -0
- dately/_vendor/__init__.py +46 -0
- dately/_vendor/agent_profile/__init__.py +59 -0
- dately/_vendor/agent_profile/scripts/__init__.py +47 -0
- dately/_vendor/agent_profile/scripts/user_agent/__init__.py +47 -0
- dately/_vendor/agent_profile/scripts/user_agent/generate.py +113 -0
- dately/_vendor/agent_profile/user_agent/README.md +37 -0
- dately/_vendor/agent_profile/user_agent/__init__.py +52 -0
- dately/_vendor/agent_profile/user_agent/browser_versions/__init__.py +45 -0
- dately/_vendor/agent_profile/user_agent/browser_versions/chrome.py +204 -0
- dately/_vendor/agent_profile/user_agent/browser_versions/edge.py +592 -0
- dately/_vendor/agent_profile/user_agent/browser_versions/safari.py +90 -0
- dately/_vendor/agent_profile/user_agent/generator.py +244 -0
- dately/_vendor/agent_profile/user_agent/headers.py +130 -0
- dately/_vendor/agent_profile/user_agent/http_session.py +96 -0
- dately/_vendor/agent_profile/user_agent/update_versions.py +119 -0
- dately/_vendor/agent_profile/user_agent/version.py +51 -0
- dately/_vendor/agent_profile/user_agent/version_sources/__init__.py +45 -0
- dately/_vendor/agent_profile/user_agent/version_sources/apple.py +102 -0
- dately/_vendor/agent_profile/user_agent/version_sources/chrome.py +85 -0
- dately/_vendor/agent_profile/user_agent/version_sources/edge.py +189 -0
- dately/_version.py +49 -0
- dately/_webutils.py +144 -0
- dately/core.py +717 -0
- dately/dt_nlp/__init__.py +44 -0
- dately/dt_nlp/arithmetic.py +1309 -0
- dately/dt_nlp/lexical_validation/__init__.py +44 -0
- dately/dt_nlp/lexical_validation/vocabulary_checks.py +114 -0
- dately/dt_nlp/quantified_time.py +208 -0
- dately/dt_nlp/relative_time.py +422 -0
- dately/dt_nlp/semantic_validation/__init__.py +44 -0
- dately/dt_nlp/semantic_validation/unit_bounds.py +380 -0
- dately/dt_nlp/string_similarity/__init__.py +44 -0
- dately/dt_nlp/string_similarity/spell_correction.py +802 -0
- dately/dt_nlp/syntactic_validation/__init__.py +44 -0
- dately/dt_nlp/syntactic_validation/structure_validator.py +320 -0
- dately/dt_nlp/syntactic_validation/temporal_structure_rules.py +543 -0
- dately/dt_nlp/temporal_core/__init__.py +44 -0
- dately/dt_nlp/temporal_core/temporal_units.py +339 -0
- dately/dt_nlp/temporal_preprocessing.py +1389 -0
- dately/files/__init__.py +44 -0
- dately/files/country_variants.json +293 -0
- dately/files/holiday.json +934 -0
- dately/files/timezone_data.json +4178 -0
- dately/mold/__init__.py +44 -0
- dately/mold/pyd/Compiled.cp313-win_amd64.pyd +0 -0
- dately/mold/pyd/__init__.py +44 -0
- dately/mold/pyd/cdatetime/UniversalDateFormatter.cp313-win_amd64.pyd +0 -0
- dately/mold/pyd/cdatetime/__init__.py +44 -0
- dately/mold/pyd/cdatetime/iso8601T.cp313-win_amd64.pyd +0 -0
- dately/mold/pyd/cdatetime/iso8601Z.cp313-win_amd64.pyd +0 -0
- dately/mold/pyd/cdatetime/whichformat.cp313-win_amd64.pyd +0 -0
- dately/mold/pyd/clean_str.cp313-win_amd64.pyd +0 -0
- dately/mold/pyd/time_zones.cp313-win_amd64.pyd +0 -0
- dately-3.3.0.dist-info/METADATA +178 -0
- dately-3.3.0.dist-info/RECORD +71 -0
- dately-3.3.0.dist-info/WHEEL +5 -0
- dately-3.3.0.dist-info/licenses/LICENSE +21 -0
- dately-3.3.0.dist-info/top_level.txt +1 -0
dately/__init__.py
ADDED
|
@@ -0,0 +1,282 @@
|
|
|
1
|
+
# -*- coding: utf-8 -*-
|
|
2
|
+
|
|
3
|
+
#
|
|
4
|
+
# doydl's Temporal Parsing & Normalization Engine — dately
|
|
5
|
+
#
|
|
6
|
+
# The `dately` module is a deterministic engine for parsing, resolving, and normalizing
|
|
7
|
+
# temporal expressions across both natural and symbolic language contexts — built for NLP
|
|
8
|
+
# workflows, cross-platform date handling, and fine-grained temporal reasoning.
|
|
9
|
+
#
|
|
10
|
+
# Designed with formal grammatical rigor, `dately` interprets phrases like “first five days of next month,”
|
|
11
|
+
# “Q3 of last year,” and “April 3” — handling cardinal/ordinal resolution, anchored structures, and
|
|
12
|
+
# ambiguous or implicit references with linguistic sensitivity.
|
|
13
|
+
#
|
|
14
|
+
# The engine combines structured tokenization, symbolic transformation, and rule-based semantic
|
|
15
|
+
# composition to support precision across tasks such as entity recognition, information extraction,
|
|
16
|
+
# and temporal normalization in noisy or informal text.
|
|
17
|
+
#
|
|
18
|
+
# It guarantees invertibility, transparency, and cross-platform consistency, resolving platform-specific
|
|
19
|
+
# formatting differences (e.g. Windows vs. Unix) while maintaining NLP-grade flexibility for English-language
|
|
20
|
+
# temporal constructions.
|
|
21
|
+
#
|
|
22
|
+
# Whether embedded in intelligent agents, ETL pipelines, or legal/medical NLP systems, `dately` brings
|
|
23
|
+
# clarity and structure to temporal meaning — bridging symbolic logic with real-world language.
|
|
24
|
+
#
|
|
25
|
+
# Copyright (c) 2024 by doydl technologies. All rights reserved.
|
|
26
|
+
#
|
|
27
|
+
# Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
28
|
+
# of this software and associated documentation files (the “Software”), to deal
|
|
29
|
+
# in the Software without restriction, including without limitation the rights
|
|
30
|
+
# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
31
|
+
# copies of the Software, and to permit persons to whom the Software is
|
|
32
|
+
# furnished to do so, subject to the following conditions:
|
|
33
|
+
#
|
|
34
|
+
# The above copyright notice and this permission notice shall be included in all
|
|
35
|
+
# copies or substantial portions of the Software.
|
|
36
|
+
#
|
|
37
|
+
# THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
38
|
+
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
39
|
+
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
40
|
+
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
41
|
+
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
42
|
+
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
43
|
+
# SOFTWARE.
|
|
44
|
+
#
|
|
45
|
+
|
|
46
|
+
"""
|
|
47
|
+
**dately** is a robust, cross-platform Python library engineered for high-precision, high-throughput
|
|
48
|
+
processing of date and time data. It unifies temporal parsing, transformation, normalization, and
|
|
49
|
+
reasoning into a coherent framework that addresses both structured datetime manipulation and the
|
|
50
|
+
interpretation of free-form natural language time expressions. Designed for developers, data
|
|
51
|
+
scientists, and system architects who treat temporal accuracy as a first-class concern, *dately*
|
|
52
|
+
delivers deterministic behavior, structural flexibility, and deep extensibility, making it suitable
|
|
53
|
+
for a wide spectrum of use cases—ranging from backend systems and ETL pipelines to conversational
|
|
54
|
+
agents and time-sensitive user interfaces.
|
|
55
|
+
|
|
56
|
+
At its foundation, **dately** abstracts the idiosyncrasies of operating system differences
|
|
57
|
+
(Unix-like systems vs. Windows), datetime format inconsistencies, locale-dependent ambiguities, and
|
|
58
|
+
malformed or user-generated inputs. It is particularly adept at bridging the divide between
|
|
59
|
+
machine-readable and human-generated temporal data, offering utilities that maintain semantic
|
|
60
|
+
integrity and consistent behavior across platforms, languages, and data formats.
|
|
61
|
+
|
|
62
|
+
─────────────────────────────────────────────────────────────────────────────────────
|
|
63
|
+
✓ Structural Parsing and Transformation
|
|
64
|
+
─────────────────────────────────────────────────────────────────────────────────────
|
|
65
|
+
The library’s core parsing engine operates across scalar and vectorized data structures—
|
|
66
|
+
supporting Python strings and datetime objects, as well as NumPy arrays, Pandas Series, JSON-style
|
|
67
|
+
dictionaries, and nested collections. This versatility allows dately to function as a drop-in
|
|
68
|
+
replacement or augmentation to standard libraries like `datetime`, `dateutil`, and `pytz`, while
|
|
69
|
+
offering significantly more nuanced handling of edge cases and malformed input.
|
|
70
|
+
|
|
71
|
+
A key component of this system is the `DateFormatFinder`, a high-performance inference engine
|
|
72
|
+
capable of deducing `strptime`-compatible format strings from unstructured or loosely formatted
|
|
73
|
+
date strings. Whether the input is ISO 8601-compliant, written in localized formats, or expressed
|
|
74
|
+
in natural language, `DateFormatFinder` intelligently reconstructs the underlying pattern to enable
|
|
75
|
+
lossless parsing and further transformation.
|
|
76
|
+
|
|
77
|
+
Beyond parsing, dately provides finely-grained manipulation of datetime components via functions
|
|
78
|
+
such as `extract_datetime_component`, `replace_datestring`, and `replace_timestring`. These
|
|
79
|
+
operations respect input structure and batch dimensions, ensuring shape consistency and
|
|
80
|
+
immutability across list-like or tabular data—essential for functional programming pipelines and
|
|
81
|
+
composable data transformations.
|
|
82
|
+
|
|
83
|
+
─────────────────────────────────────────────────────────────────────────────────────
|
|
84
|
+
✓ Time Zone Normalization and Cross-Platform Precision
|
|
85
|
+
─────────────────────────────────────────────────────────────────────────────────────
|
|
86
|
+
One of dately’s most differentiated capabilities lies in its advanced time zone infrastructure.
|
|
87
|
+
Unlike libraries that depend on system-level time zone behavior or fail to reconcile
|
|
88
|
+
inconsistencies across platforms, dately introduces a fully normalized, OS-agnostic layer for time
|
|
89
|
+
zone operations. It supports conversions between IANA zone identifiers and UTC offsets, manages
|
|
90
|
+
daylight saving time (DST) transitions with high fidelity, and enables temporal classification
|
|
91
|
+
based on geopolitical and regional rules.
|
|
92
|
+
|
|
93
|
+
Moreover, the library resolves long-standing compatibility issues with the `strftime`/`strptime`
|
|
94
|
+
family of format specifiers—particularly those that misbehave or are unsupported in Windows
|
|
95
|
+
environments. Through regex-driven patching, intelligent specifier substitution, and output-aware
|
|
96
|
+
postprocessing, dately guarantees format consistency across Linux, Windows, and macOS. This feature
|
|
97
|
+
is especially valuable in CI/CD workflows, cross-platform APIs, Docker-based services, and
|
|
98
|
+
multi-environment scheduling applications.
|
|
99
|
+
|
|
100
|
+
─────────────────────────────────────────────────────────────────────────────────────
|
|
101
|
+
✓ Performance and Vectorized Workflows
|
|
102
|
+
─────────────────────────────────────────────────────────────────────────────────────
|
|
103
|
+
dately has been optimized for high-performance execution. It employs vectorized operations
|
|
104
|
+
throughout its API and optionally leverages Cython and compiled C extensions to accelerate
|
|
105
|
+
time-critical workflows. This makes it ideal for integration into high-volume data engineering
|
|
106
|
+
tasks, including time-series feature extraction, log processing, and real-time data ingestion
|
|
107
|
+
pipelines.
|
|
108
|
+
|
|
109
|
+
Utilities such as `convert_date`, `sequence` (for generating inclusive or offset-aware date ranges),
|
|
110
|
+
and composable format converters allow users to build modular, declarative pipelines for datetime
|
|
111
|
+
transformation. Each utility is designed for integration into larger systems, with support for
|
|
112
|
+
input validation, error recovery, and structural introspection.
|
|
113
|
+
|
|
114
|
+
─────────────────────────────────────────────────────────────────────────────────────
|
|
115
|
+
✓ Natural Language Processing (NLP) for Temporal Reasoning
|
|
116
|
+
─────────────────────────────────────────────────────────────────────────────────────
|
|
117
|
+
In addition to structured parsing, dately features a purpose-built symbolic NLP engine for
|
|
118
|
+
resolving natural language time expressions into discrete datetime values or bounded intervals.
|
|
119
|
+
This engine does not rely on opaque machine learning models; instead, it uses a deterministic,
|
|
120
|
+
rule-based architecture that offers full transparency and auditability—critical for
|
|
121
|
+
compliance-heavy domains such as healthcare, legal tech, and financial systems.
|
|
122
|
+
|
|
123
|
+
The NLP pipeline consists of five stages:
|
|
124
|
+
1. **Lexical Normalization** – Converts words to their numeric or canonical forms (e.g.,
|
|
125
|
+
“second Friday” → ordinal(2), weekday=Friday).
|
|
126
|
+
2. **Grammar Parsing** – Applies symbolic pattern recognition to identify structural motifs like
|
|
127
|
+
anchored offsets or nested intervals.
|
|
128
|
+
3. **Calendar Logic Resolution** – Translates abstract concepts (e.g., “weekends,” “next quarter”)
|
|
129
|
+
into concrete calendar dates using arithmetic models.
|
|
130
|
+
4. **Contextual Grounding** – Resolves ambiguous references (e.g., “this month”) relative to a
|
|
131
|
+
configurable `reference_date`.
|
|
132
|
+
5. **Structured Output Emission** – Produces standardized `datetime.date` objects or normalized
|
|
133
|
+
ranges ready for downstream use.
|
|
134
|
+
|
|
135
|
+
This NLP component handles a wide array of expressions—absolute dates, ordinal references,
|
|
136
|
+
recurring intervals, seasonal phrases, and anchored relative durations. It excels at parsing
|
|
137
|
+
partially specified input (e.g., “Q3 2023”), vague phrasings (“a week before tax day”), and
|
|
138
|
+
colloquial constructs (“last few Fridays”). Crucially, the outputs are consistent, interpretable,
|
|
139
|
+
and suitable for rule-based scheduling, time-based querying, or human-in-the-loop validation
|
|
140
|
+
systems.
|
|
141
|
+
|
|
142
|
+
─────────────────────────────────────────────────────────────────────────────────────
|
|
143
|
+
✓ Integrated, Modular Design Philosophy
|
|
144
|
+
─────────────────────────────────────────────────────────────────────────────────────
|
|
145
|
+
What sets dately apart is its deliberate emphasis on modularity, clarity, and cross-domain
|
|
146
|
+
applicability. Its components can be used independently or orchestrated together, allowing
|
|
147
|
+
developers to treat time not merely as a data field, but as a richly structured domain of meaning.
|
|
148
|
+
Whether you're building a chatbot that schedules meetings, a pipeline that deduplicates
|
|
149
|
+
time-stamped records, or an application that reconciles logs across time zones, dately offers the
|
|
150
|
+
primitives and abstractions needed to ensure reliable temporal computation.
|
|
151
|
+
|
|
152
|
+
By harmonizing symbolic reasoning, deterministic NLP, and high-throughput engineering, dately
|
|
153
|
+
elevates temporal data from an error-prone nuisance to a rigorously modeled, first-class element of
|
|
154
|
+
modern software architecture.
|
|
155
|
+
"""
|
|
156
|
+
if __package__:
|
|
157
|
+
from . import core as __core
|
|
158
|
+
from ._api import set_week_start
|
|
159
|
+
from ._version import __version__
|
|
160
|
+
else: # Allows test collectors to import this flat-layout package initializer.
|
|
161
|
+
from dately import core as __core
|
|
162
|
+
from dately._api import set_week_start
|
|
163
|
+
from dately._version import __version__
|
|
164
|
+
|
|
165
|
+
|
|
166
|
+
__all__ = [
|
|
167
|
+
'extract_datetime_component',
|
|
168
|
+
'detect_date_format',
|
|
169
|
+
'convert_date',
|
|
170
|
+
'replace_timestring',
|
|
171
|
+
'replace_datestring',
|
|
172
|
+
'sequence',
|
|
173
|
+
'parse',
|
|
174
|
+
'set_week_start',
|
|
175
|
+
'__version__',
|
|
176
|
+
'Holidate',
|
|
177
|
+
'TimeZoner',
|
|
178
|
+
]
|
|
179
|
+
|
|
180
|
+
# Reference functions using __core alias
|
|
181
|
+
extract_datetime_component = __core.extract_datetime_component
|
|
182
|
+
detect_date_format = __core.detect_date_format
|
|
183
|
+
convert_date = __core.convert_date
|
|
184
|
+
replace_timestring = __core.replace_timestring
|
|
185
|
+
replace_datestring = __core.replace_datestring
|
|
186
|
+
sequence = __core.sequence
|
|
187
|
+
parse = __core.parse
|
|
188
|
+
|
|
189
|
+
# Remove core to keep namespace clean without relying on import side effects.
|
|
190
|
+
globals().pop('core', None)
|
|
191
|
+
|
|
192
|
+
# Import the real types and their lazy factories. Constructing either feature is
|
|
193
|
+
# local-only; network access occurs only when a network-backed method is called.
|
|
194
|
+
if __package__:
|
|
195
|
+
from ._holiday import HolidayManager
|
|
196
|
+
from ._proxy import proxyObj as _proxyObj
|
|
197
|
+
from ._timezone import ZoneInfoManager
|
|
198
|
+
else:
|
|
199
|
+
from dately._holiday import HolidayManager
|
|
200
|
+
from dately._proxy import proxyObj as _proxyObj
|
|
201
|
+
from dately._timezone import ZoneInfoManager
|
|
202
|
+
|
|
203
|
+
# -----------------------------
|
|
204
|
+
# TimeZoner - Stub for Autocomplete/Docs
|
|
205
|
+
# -----------------------------
|
|
206
|
+
class TimeZonerStub:
|
|
207
|
+
"""
|
|
208
|
+
TimeZoner manages all timezone interactions.
|
|
209
|
+
|
|
210
|
+
Methods:
|
|
211
|
+
ConvertTimeZone(from_zone, to_zone, year=None, month=None, day=None, hour=None, minute=None, second=None)
|
|
212
|
+
CurrentTimebyZone(zone_name)
|
|
213
|
+
FilterZoneDetail(zone_name)
|
|
214
|
+
|
|
215
|
+
Properties:
|
|
216
|
+
Zones, ZonesByCountry, Offsets, ObservesDST, CountryNames, CountryCodes
|
|
217
|
+
"""
|
|
218
|
+
def ConvertTimeZone(self, from_zone, to_zone, year=None, month=None, day=None, hour=None, minute=None, second=None): pass
|
|
219
|
+
def CurrentTimebyZone(self, zone_name): pass
|
|
220
|
+
def FilterZoneDetail(self, zone_name): pass
|
|
221
|
+
|
|
222
|
+
@property
|
|
223
|
+
def Zones(self): pass
|
|
224
|
+
@property
|
|
225
|
+
def ZonesByCountry(self): pass
|
|
226
|
+
@property
|
|
227
|
+
def Offsets(self): pass
|
|
228
|
+
@property
|
|
229
|
+
def ObservesDST(self): pass
|
|
230
|
+
@property
|
|
231
|
+
def CountryNames(self): pass
|
|
232
|
+
@property
|
|
233
|
+
def CountryCodes(self): pass
|
|
234
|
+
|
|
235
|
+
TimeZoner: ZoneInfoManager = _proxyObj('dately._timezone', 'get_TimeZoner')
|
|
236
|
+
TimeZoner.__doc__ = TimeZonerStub.__doc__
|
|
237
|
+
|
|
238
|
+
# -----------------------------
|
|
239
|
+
def timezoner_stub_dir():
|
|
240
|
+
return ['ConvertTimeZone', 'CurrentTimebyZone', 'FilterZoneDetail',
|
|
241
|
+
'Zones', 'ZonesByCountry', 'Offsets', 'ObservesDST',
|
|
242
|
+
'CountryNames', 'CountryCodes']
|
|
243
|
+
|
|
244
|
+
# --------------------------------------
|
|
245
|
+
# Holidate - Stub for Autocomplete/Docs
|
|
246
|
+
# --------------------------------------
|
|
247
|
+
class HolidateStub:
|
|
248
|
+
"""
|
|
249
|
+
Holidate manages holiday data retrieval.
|
|
250
|
+
|
|
251
|
+
Methods:
|
|
252
|
+
ListCountries
|
|
253
|
+
Holiday(country_name, year=None, format='list')
|
|
254
|
+
"""
|
|
255
|
+
@property
|
|
256
|
+
def ListCountries(self): pass
|
|
257
|
+
|
|
258
|
+
def Holiday(self, country_name, year=None, format='list'): pass
|
|
259
|
+
|
|
260
|
+
Holidate: HolidayManager = _proxyObj('dately._holiday', 'get_Holidate')
|
|
261
|
+
Holidate.__doc__ = HolidateStub.__doc__
|
|
262
|
+
|
|
263
|
+
# -----------------------------
|
|
264
|
+
def holidate_stub_dir():
|
|
265
|
+
return ['ListCountries', 'Holiday']
|
|
266
|
+
|
|
267
|
+
|
|
268
|
+
# ------------------------------------------
|
|
269
|
+
# Expose all symbols defined in __init__.py
|
|
270
|
+
# ------------------------------------------
|
|
271
|
+
def __dir__():
|
|
272
|
+
base_dir = globals().keys()
|
|
273
|
+
base_dir = [f for f in base_dir if f.startswith("__") and f.endswith("__")]
|
|
274
|
+
return sorted(set(base_dir).union(
|
|
275
|
+
{
|
|
276
|
+
'extract_datetime_component', 'detect_date_format', 'convert_date',
|
|
277
|
+
'replace_timestring', 'replace_datestring', 'sequence', 'parse',
|
|
278
|
+
'set_week_start', '__version__', 'Holidate', 'TimeZoner'
|
|
279
|
+
}
|
|
280
|
+
)
|
|
281
|
+
)
|
|
282
|
+
|
dately/_api.py
ADDED
|
@@ -0,0 +1,85 @@
|
|
|
1
|
+
# -*- coding: utf-8 -*-
|
|
2
|
+
|
|
3
|
+
#
|
|
4
|
+
# doydl's Temporal Parsing & Normalization Engine — dately
|
|
5
|
+
#
|
|
6
|
+
# The `dately` module is a deterministic engine for parsing, resolving, and normalizing
|
|
7
|
+
# temporal expressions across both natural and symbolic language contexts — built for NLP
|
|
8
|
+
# workflows, cross-platform date handling, and fine-grained temporal reasoning.
|
|
9
|
+
#
|
|
10
|
+
# Designed with formal grammatical rigor, `dately` interprets phrases like “first five days of next month,”
|
|
11
|
+
# “Q3 of last year,” and “April 3” — handling cardinal/ordinal resolution, anchored structures, and
|
|
12
|
+
# ambiguous or implicit references with linguistic sensitivity.
|
|
13
|
+
#
|
|
14
|
+
# The engine combines structured tokenization, symbolic transformation, and rule-based semantic
|
|
15
|
+
# composition to support precision across tasks such as entity recognition, information extraction,
|
|
16
|
+
# and temporal normalization in noisy or informal text.
|
|
17
|
+
#
|
|
18
|
+
# It guarantees invertibility, transparency, and cross-platform consistency, resolving platform-specific
|
|
19
|
+
# formatting differences (e.g. Windows vs. Unix) while maintaining NLP-grade flexibility for English-language
|
|
20
|
+
# temporal constructions.
|
|
21
|
+
#
|
|
22
|
+
# Whether embedded in intelligent agents, ETL pipelines, or legal/medical NLP systems, `dately` brings
|
|
23
|
+
# clarity and structure to temporal meaning — bridging symbolic logic with real-world language.
|
|
24
|
+
#
|
|
25
|
+
# Copyright (c) 2024 by doydl technologies. All rights reserved.
|
|
26
|
+
#
|
|
27
|
+
# Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
28
|
+
# of this software and associated documentation files (the “Software”), to deal
|
|
29
|
+
# in the Software without restriction, including without limitation the rights
|
|
30
|
+
# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
31
|
+
# copies of the Software, and to permit persons to whom the Software is
|
|
32
|
+
# furnished to do so, subject to the following conditions:
|
|
33
|
+
#
|
|
34
|
+
# The above copyright notice and this permission notice shall be included in all
|
|
35
|
+
# copies or substantial portions of the Software.
|
|
36
|
+
#
|
|
37
|
+
# THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
38
|
+
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
39
|
+
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
40
|
+
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
41
|
+
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
42
|
+
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
43
|
+
# SOFTWARE.
|
|
44
|
+
#
|
|
45
|
+
|
|
46
|
+
from ._log import logger
|
|
47
|
+
from ._temporal_scan import resolver
|
|
48
|
+
|
|
49
|
+
|
|
50
|
+
|
|
51
|
+
# Library-level convenience: tweak the singleton’s week start in one call
|
|
52
|
+
def set_week_start(day):
|
|
53
|
+
"""
|
|
54
|
+
Set the first day of the week used by the resolver.
|
|
55
|
+
|
|
56
|
+
This method updates the internal `week_start` configuration, which affects
|
|
57
|
+
how calendar-based computations (such as weeks, weekends, or expressions like
|
|
58
|
+
"start of next week") are anchored and resolved. It supports either a weekday
|
|
59
|
+
name ("sunday" or "monday") or a numeric index (0–6), where:
|
|
60
|
+
- 0 = Monday
|
|
61
|
+
- 6 = Sunday
|
|
62
|
+
|
|
63
|
+
Parameters:
|
|
64
|
+
──────────────────────────
|
|
65
|
+
week_start : str | int
|
|
66
|
+
The desired first day of the week. Accepts:
|
|
67
|
+
- A string: "sunday" or "monday"
|
|
68
|
+
- An integer: 0 (for Monday) or 6 (for Sunday)
|
|
69
|
+
|
|
70
|
+
Returns:
|
|
71
|
+
──────────────────────────
|
|
72
|
+
None
|
|
73
|
+
|
|
74
|
+
Example:
|
|
75
|
+
──────────────────────────
|
|
76
|
+
>>> resolver.set_week_start("monday")
|
|
77
|
+
>>> resolver.set_week_start(0) # Also sets to Monday
|
|
78
|
+
"""
|
|
79
|
+
resolver.set_week_start(day)
|
|
80
|
+
|
|
81
|
+
# Informative log message (quiet unless the user enables it) -------------
|
|
82
|
+
logger.info("Week-start updated → %s", resolver.week_start.capitalize())
|
|
83
|
+
|
|
84
|
+
__all__ = ["set_week_start"]
|
|
85
|
+
|