@blackcode_sa/metaestetics-api 1.12.24 → 1.12.26

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.
package/dist/index.js CHANGED
@@ -9405,7 +9405,7 @@ var ClinicService = class extends BaseService {
9405
9405
  this.clinicAdminService = clinicAdminService;
9406
9406
  this.clinicGroupService = clinicGroupService;
9407
9407
  this.mediaService = mediaService;
9408
- this.functions = (0, import_functions2.getFunctions)(app);
9408
+ this.functions = (0, import_functions2.getFunctions)(app, "europe-west6");
9409
9409
  }
9410
9410
  /**
9411
9411
  * Get timezone from coordinates using the callable function
@@ -9539,6 +9539,7 @@ var ClinicService = class extends BaseService {
9539
9539
  const location = validatedData.location;
9540
9540
  const hash = (0, import_geofire_common7.geohashForLocation)([location.latitude, location.longitude]);
9541
9541
  const tz = await this.getTimezone(location.latitude, location.longitude);
9542
+ console.log("\u{1F3E5} Clinic timezone:", tz);
9542
9543
  const defaultReviewInfo = {
9543
9544
  totalReviews: 0,
9544
9545
  averageRating: 0,
package/dist/index.mjs CHANGED
@@ -9510,7 +9510,7 @@ var ClinicService = class extends BaseService {
9510
9510
  this.clinicAdminService = clinicAdminService;
9511
9511
  this.clinicGroupService = clinicGroupService;
9512
9512
  this.mediaService = mediaService;
9513
- this.functions = getFunctions2(app);
9513
+ this.functions = getFunctions2(app, "europe-west6");
9514
9514
  }
9515
9515
  /**
9516
9516
  * Get timezone from coordinates using the callable function
@@ -9644,6 +9644,7 @@ var ClinicService = class extends BaseService {
9644
9644
  const location = validatedData.location;
9645
9645
  const hash = geohashForLocation4([location.latitude, location.longitude]);
9646
9646
  const tz = await this.getTimezone(location.latitude, location.longitude);
9647
+ console.log("\u{1F3E5} Clinic timezone:", tz);
9647
9648
  const defaultReviewInfo = {
9648
9649
  totalReviews: 0,
9649
9650
  averageRating: 0,
package/package.json CHANGED
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "@blackcode_sa/metaestetics-api",
3
3
  "private": false,
4
- "version": "1.12.24",
4
+ "version": "1.12.26",
5
5
  "description": "Firebase authentication service with anonymous upgrade support",
6
6
  "main": "dist/index.js",
7
7
  "module": "dist/index.mjs",
@@ -0,0 +1,141 @@
1
+ ## Booking timezones and time types: current state, issues, and alignment plan
2
+
3
+ ### Scope and goal
4
+ This document explains how booking availability is computed across the admin layer and calculator, how time types and timezones are used today, where mismatches occur, and what to align to make results consistent in every environment and across DST.
5
+
6
+ Applies to:
7
+ - `Api/src/admin/booking/booking.admin.ts`
8
+ - `Api/src/admin/booking/booking.calculator.ts`
9
+ - `Api/src/admin/booking/booking.types.ts`
10
+
11
+ ### High-level flow (availability)
12
+ 1) `BookingAdmin.getAvailableBookingSlots`
13
+ - Accepts timeframe as `Date` or `admin.firestore.Timestamp` and normalizes to admin Timestamp.
14
+ - Loads `clinic`, `practitioner`, `procedure`.
15
+ - Fetches calendar events for clinic and practitioner within the timeframe using admin Timestamps.
16
+ - Converts all timestamps (timeframe and events) to client `firebase/firestore` `Timestamp` for the calculator via `TimestampUtils.adminToClient`.
17
+ - Passes clinic timezone `tz = clinic.location.tz` to the calculator.
18
+ - Calls `BookingAvailabilityCalculator.calculateSlots`.
19
+ - Converts resulting client `Timestamp`s back to admin Timestamp in the response.
20
+
21
+ 2) `BookingAvailabilityCalculator.calculateSlots`
22
+ - Uses client `Timestamp` + Luxon `DateTime`.
23
+ - Steps: apply clinic working hours → subtract clinic blocking events → apply practitioner working hours for the target clinic → subtract practitioner busy times → generate slots on a fixed interval grid.
24
+
25
+ 3) Types (`BookingAvailabilityRequest`)
26
+ - Requires that all time values be client `Timestamp` (from `firebase/firestore`).
27
+ - Admin layer converts before calling the calculator and converts back afterwards.
28
+
29
+ ### Time representations in play
30
+ - Admin/server: `admin.firestore.Timestamp` (backend)
31
+ - Client/runtime in calculator: `firebase/firestore` `Timestamp`
32
+ - Luxon `DateTime` for tz-aware computations
33
+ - String wall-clock specs in working hours, e.g. "HH:mm" for open/close/breaks
34
+ - JavaScript `Date` only used transiently at boundaries
35
+
36
+ ### Where timezone handling is correct
37
+ - Building per-day working-hour intervals (clinic and practitioner) uses:
38
+ - `DateTime.fromMillis(value, { zone: tz })` (avoids local-time reinterpretation)
39
+ - Explicit `tz` carried from `clinic.location.tz`
40
+
41
+ ### Where timezone context is dropped (root cause of shifts)
42
+ - Slot generation rounds and iterates using system-local timezone instead of clinic `tz`.
43
+ - Slot containment checks compare times constructed without explicit `tz`.
44
+ - Effects:
45
+ - Servers not in the clinic’s zone (e.g., UTC) will produce slots offset or misaligned to the expected clinic grid.
46
+ - DST boundaries can produce off-by-60-min effects and incorrect inclusion/exclusion of slots.
47
+
48
+ Problematic patterns to replace:
49
+ ```ts
50
+ // Uses system-local timezone implicitly
51
+ let slotStart = DateTime.fromJSDate(intervalStart);
52
+
53
+ // Also builds DateTimes without { zone: tz }
54
+ const intervalStart = DateTime.fromMillis(interval.start.toMillis());
55
+ const intervalEnd = DateTime.fromMillis(interval.end.toMillis());
56
+ ```
57
+
58
+ Target pattern:
59
+ ```ts
60
+ // Always specify the clinic timezone
61
+ let slotStart = DateTime.fromMillis(intervalStartMillis, { zone: tz });
62
+ const intervalStart = DateTime.fromMillis(interval.start.toMillis(), { zone: tz });
63
+ const intervalEnd = DateTime.fromMillis(interval.end.toMillis(), { zone: tz });
64
+ ```
65
+
66
+ ### Event retrieval misses overlapping events
67
+ - Current queries fetch events with `eventTime.start` within `[timeframe.start, timeframe.end]` only.
68
+ - Events that start before the window but overlap into it (or extend beyond it) are omitted, so busy time subtraction can miss conflicts.
69
+
70
+ Correct overlapping logic should include events where:
71
+ - `eventTime.start < timeframe.end` AND `eventTime.end > timeframe.start`
72
+
73
+ Firestore considerations:
74
+ - Firestore cannot do range filters on two different fields in a single query without workarounds. Practical options:
75
+ - Run two queries and union results, or
76
+ - Add a single-field index (e.g., duplicated fields like `startAt` and `endAt`) and leverage composite queries appropriately, or
77
+ - Query the broader of the two constraints and post-filter in memory. De-duplicate by `id`.
78
+
79
+ ### Appointment creation normalization
80
+ - `orchestrateAppointmentCreation` writes calendar events with `eventTime` taken directly from input admin Timestamps.
81
+ - If the client produced those Timestamps by converting wall-clock times in a different timezone than the clinic, users will observe unexpected local renderings relative to clinic working hours.
82
+
83
+ Alignment expectation:
84
+ - UI should interpret user-picked wall-clock times in the clinic’s `tz`, convert once to UTC epoch, and send as Timestamp.
85
+ - Backend stores the UTC epoch as-is; all display/logic that needs wall-clock context must apply the clinic `tz` explicitly.
86
+
87
+ ### Alignment decisions (non-code policy)
88
+ 1) Single invariant for the calculator
89
+ - Inputs are client `Timestamp`s (UTC epoch) plus explicit `tz`.
90
+ - Every Luxon `DateTime` must be created with `{ zone: tz }`.
91
+ - Prefer `DateTime.fromMillis(...)` over `fromJSDate(...)`.
92
+
93
+ 2) Slot generation/containment
94
+ - `generateAvailableSlots` uses `tz` when rounding to interval grid and when iterating.
95
+ - `isSlotFullyAvailable` constructs interval boundaries with `{ zone: tz }`.
96
+
97
+ 3) Event retrieval strategy
98
+ - For timeframe `[S, E]`, include events where `start < E` and `end > S`.
99
+ - Implement via union of queries or data model support; post-filter and de-dup in memory if needed.
100
+
101
+ 4) Conversion boundaries
102
+ - Admin layer converts admin → client Timestamps only at the calculator boundary and client → admin at the response boundary.
103
+ - Do not mix admin/client Timestamp types in a single object passed to the calculator.
104
+
105
+ 5) UI and API contract
106
+ - UI times are wall-clock in clinic `tz`, converted once to UTC Timestamp before sending.
107
+ - Backend accepts/returns admin Timestamps on API, but calculator-only paths use client Timestamps internally.
108
+
109
+ ### Testing matrix (must pass)
110
+ - Timezone variance:
111
+ - Clinics in multiple IANA zones; server in UTC and in a non-UTC zone.
112
+ - DST boundaries:
113
+ - Days that enter/exit DST in clinic `tz`.
114
+ - Timeframe edges:
115
+ - Windows that straddle midnight in clinic `tz`.
116
+ - Very short windows (e.g., ≤ duration) and long windows (multi-day).
117
+ - Event overlap cases:
118
+ - Events starting before S and ending between S..E.
119
+ - Events starting between S..E and ending after E.
120
+ - Long events fully covering S..E.
121
+ - Grid checks:
122
+ - Interval sizes that don’t divide 60 (e.g., 20 min), and variable procedure durations.
123
+
124
+ ### Actionable checklist
125
+ - Make all DateTime constructions in slot generation and containment checks use `{ zone: tz }`.
126
+ - Replace `fromJSDate` with `fromMillis` in calculator paths.
127
+ - Update event fetching to include overlaps with the timeframe; union queries or adjust model.
128
+ - Re-assert the type contract: calculator receives only client `Timestamp` + `tz`.
129
+ - Document UI responsibility to convert wall-clock (clinic `tz`) → UTC Timestamp exactly once.
130
+
131
+ ### Known risks
132
+ - DST transitions can produce days with 23/25 hours; rounding/iteration must not assume 24h.
133
+ - Post-filtering events after union queries can be memory-intensive for very large windows; constrain timeframe appropriately.
134
+
135
+ ### Quick glossary
136
+ - Admin Timestamp: `admin.firestore.Timestamp` (backend SDK)
137
+ - Client Timestamp: `firebase/firestore` `Timestamp` (web SDK)
138
+ - `tz`: Clinic’s IANA timezone string, e.g., `Europe/Belgrade`
139
+ - Luxon `DateTime`: tz-aware date-time object used for calendar math
140
+
141
+
@@ -17,7 +17,7 @@ import {
17
17
  arrayUnion,
18
18
  arrayRemove,
19
19
  } from "firebase/firestore";
20
- import { getFunctions, httpsCallable } from "firebase/functions";
20
+ import { getFunctions, httpsCallable, connectFunctionsEmulator } from "firebase/functions";
21
21
  import { BaseService } from "../base.service";
22
22
  import {
23
23
  Clinic,
@@ -78,7 +78,7 @@ export class ClinicService extends BaseService {
78
78
  this.clinicAdminService = clinicAdminService;
79
79
  this.clinicGroupService = clinicGroupService;
80
80
  this.mediaService = mediaService;
81
- this.functions = getFunctions(app);
81
+ this.functions = getFunctions(app, "europe-west6"); // All functions now in europe-west6
82
82
  }
83
83
 
84
84
  /**
@@ -250,7 +250,7 @@ export class ClinicService extends BaseService {
250
250
  const location = validatedData.location;
251
251
  const hash = geohashForLocation([location.latitude, location.longitude]);
252
252
  const tz = await this.getTimezone(location.latitude, location.longitude);
253
-
253
+ console.log("🏥 Clinic timezone:", tz);
254
254
  const defaultReviewInfo: ClinicReviewInfo = {
255
255
  totalReviews: 0,
256
256
  averageRating: 0,