qrono 1.4.0 → 1.5.0

package/README.md

@@ -1,4 +1,4 @@
-# <img src="docs/public/logo.svg" alt="Qrono Logo" width="48"> [Qrono](https://qronojs.dev/) — Small. Complete. Deterministic. JavaScript date-time.
+# <img src="docs/public/logo.svg" alt="Qrono Logo" width="48"> [Qrono](https://qronojs.dev/) — Small. Complete. Deterministic. JavaScript date-time.
 
 _**4kB** JavaScript date library with **100+ APIs** and **strict DST guarantees**. Designed for **single-timezone** applications._
 
@@ -30,7 +30,11 @@ date.weekOfYear()  // 24
 date.endOfMonth()  // 2024-06-30
 ```
 
-[🌐 Website<sup> ↗</sup>](https://qronojs.dev/) \| [🎨 Design philosophy](#design-philosophy-) \| [📥 Getting started](#getting-started-) \| [🚀 Quick tour](#quick-tour-) \| [🌏 License](#license-)
+[🌐 Website<sup> ↗</sup>](https://qronojs.dev/)
+\| [🎨 Design philosophy](#design-philosophy-)
+\| [📥 Getting started](#getting-started-)
+\| [🚀 Quick tour](#quick-tour-)
+\| [🌏 License](#license-)
 
 ---
 
@@ -95,50 +99,6 @@ This comparison shows that **Qrono stands out for its small codebase** among oth
 
 For many of the other libraries, their larger size is due to the fact that a significant portion of the codebase is dedicated to supporting a wide range of locales. Meanwhile, the larger size of date-fns is intentional and not a drawback. It is designed with tree-shaking in mind, so unused functions are removed at build time, and its API is intentionally fine-grained and verbose to provide clarity and flexibility. The size difference therefore represents a difference in design philosophy, not a measure of overall quality.
 
-### Supporting Only the Local Time of the Execution Environment
-
-When handling time in a globally accessible web application, careful consideration is required for local time.
-
-In general, the server does not know the user’s actual time zone or the time zone of the client environment (OS).
-If the system needs to be aware of the user’s time zone, an application-level mechanism to manage time zones becomes necessary. In practice, however, the user’s time zone is usually assumed to be the same as the client environment’s (OS) time zone.
-
-For example, a user who resides in Japan may start using the application in the United States. If the user changes the OS time zone to match the local time in the United States, this will be done automatically in most cases, such as when the environment is a smart device; the client environment's time zone will differ from the one that is managed in the server. Considering the large number of such edge cases, it is impractical for a server-side application to manage each user's intended time zone in a database-like manner.
-
-For this reason, to keep the system design simple, the server should avoid managing user-specific time zones. Instead, the server should store and handle time exclusively in UTC. All time values should be transmitted to clients in UTC (typically as ISO 8601–formatted strings), and converting them into local time should be the responsibility of the client.
-
-Even when support for multiple locales is required, storing time data in UTC is usually sufficient. In most cases, locale-specific formatting can be handled entirely on the client side by using the [ECMAScript Internationalization API](https://402.ecma-international.org/#overview).
-
-One important caveat of this design is that the time zone database of the client environment (OS) must be properly maintained. Daylight saving time rules — for example, in Brazil — may change from year to year, and time zone definitions themselves are determined by laws that are frequently revised. This means that the underlying time zone database must be kept up to date.
-
-If the application is used in a closed or unmanaged environment where such updates cannot be applied due to special constraints, the approach described above may be insufficient.
-
-In most typical environments, this requirement is satisfied automatically through the operating system’s regular update mechanisms, so it does not pose a practical issue for the majority of applications. However, if the application is used in a closed or unmanaged environment where such updates cannot be applied due to special constraints, the approach described above may be insufficient.
-
-Considering these factors, **Qrono** is deliberately designed to forgo support for multiple time zones in order to achieve greater overall benefits, such as a **small code base and easy handling of daylight saving time transitions**.
-
-### About Daylight Saving Time
-
-Qrono is the only JavaScript date-time library with dedicated APIs for DST handling (`hasOffsetChangeInYear()`, `isInDst()`, `hasOffsetChangeInDay()`, `minutesInDay()`).
-
-JavaScript's `Date` object can behave in non-intuitive ways when handling daylight saving time transitions.
-
-For example, see the following scenario in the Central Standard Time (CST) zone of the USA:
-
-```javascript
-const date = new Date('2021-03-14T03:00:00.000')
-date.setMilliseconds(-1) // results 2021-03-14 03:59:59.999 CST
-```
-
-On March 14, 2021, daylight saving time begins. The time jumps directly from `2021-03-14 01:59:59 CST` to `2021-03-14 03:00:00 CST`.
-
-In this example, subtracting 1 millisecond from `2021-03-14 03:00:00.000 CST` results in `2021-03-14 03:59:59.999 CST`. This appears to be a simple subtraction of 1 millisecond, but it actually advances the time by 1 hour.
-
-This behavior is not a bug but a result of strictly following the [ECMAScript specification](https://262.ecma-international.org/11.0/#sec-local-time-zone-adjustment).
-
-Additionally, a `Date` object created from a duplicated time during daylight saving time (DST) transition always refers to the time before DST ends. In other words, there is no simple way to obtain a `Date` object that refers to the UTC time **after** the end of DST from a duplicated time.
-
-**Qrono** addresses these issues by providing a more understandable approach to handling such transitions.
-
 ## Getting started 📥
 
 ```sh
@@ -366,5 +326,5 @@ Copyright (c) 2021 [Urin](https://github.com/urin)
 
 [image-size]: https://img.badgesize.io/https://unpkg.com/qrono/dist/qrono.min.js?compression=gzip&color=blue
 [url-size]: https://unpkg.com/qrono/dist/qrono.min.js
-
-
+
+