Concerns & flaws with timezone parsing & handling

[LJNeon]

I've noticed that there are quite a few open issues that involve timezones (#385, #403, #532, #546, #552, #564, #582, & possibly more).

Almost all of these would be fixed with three changes:

• Use the IANA timezone database.
• Treat timezones differently based on their source, e.g. parsed from natural language or timezones supplied to the library as an option.
• Detect entirely relative times when parsing natural language and don't apply timezones to them. (And also add a matching boolean property to the output?)

Using the IANA timezone database would allow you to support longer timezone codes like "America/Los_Angeles" as well as correctly handle dates in the past when different daylight savings rules were in effect.
Separated timezone logic would resolve #564: CET would be handled with daylight savings if passed as part of the input string and handled as an absolute time if passed as a timezone. This would account for the common usage as well as the expectation of developers.
And not applying the timezone handling to relative times when unnecessary would prevent parsing issues related to relative times and timezones from even occurring in the first place.

After doing some research and experimentation I found the timezonecomplete library on npm and it seems to be exactly what would be needed to handle all of these issues. It would also be very nice to be able to outsource timezone logic to a dedicated library due to how complicated and prone to change it is.

I'm willing to open a PR (or several) for this, would just want to confirm how they should behave first.

[kimjuan]

    // Note: Many sources define CET as a constant UTC+1. In common usage, however,
    // CET usually refers to the time observed in most of Europe, be it standard time or daylight saving time.

No one living in CET can code better than @wanasit and authors of this wonderful project, but anyone living with DST will know the above is incorrect.

"CET refers to the time observed" Only In Wikipedia.

If use as a literal in a datetime, CET (or any abbreviation) is always an alias to an constant offset. #564 is absolutely spotted on.

If I watch TV commercial "Live on 25th April 15:00 CET". I will call their hotline,
Either one of the two will happen:

1. Yes, we mean CET.
2. Thank you for spotting this typo, we will correct it to CEST asap.

Under no scenario, Dear, don't you know CET in April auto compute to CEST, like Europe/Berlin.

That maybe why IANA is invented and what IANA is for.

There are many countries today, past, future, using CET but doesn't observe DST. To use this parser-powered datetime-picker, can imagine every ~March-to-July, their users need to manually offset 1hour from their input, such that it refers to that specific moment in their mind.

I apologise for ELI5 style. It is clearly a non-coding non-technical issue.

[LJNeon]

I've asked a few friends who live in Europe and done some minimal online research, and the consensus does seem to be that generally speaking they personally use CET to refer to the time observed. However that is how people use it not necessarily how a TV commercial may use it. And obviously that can't be applied to the entirety of Europe but it does seem to indicate that common usage of CET is not as simple as you've indicated.

But I do completely agree with your assertion that it would be better to use IANA timezones.

[kimjuan]

Look like you overcomplicated timezones.

CET as a symbol prefixing or suffixing a datetime-lookalike on a datetime string is a straightforward alias GMT+1,

If we want GMT+2, we type C E S T.

your assertion that it would be better to use IANA timezones.

No, I didn't.

IANA isn't even designed to be part of datetime string, it is designed for "select your timezone" Dropdown and system configuration. Imagine the nightmare if the choices are "CET / EET", tunisians will be confused at the hour saved despite living on equator.

[LJNeon]

CET as a symbol prefixing or suffixing a datetime-lookalike on a datetime string is a straightforward alias GMT+1,

As I said, that is not the case.

IANA isn't even designed to be part of datetime string, it is designed for "select your timezone" Dropdown and system configuration.

Yes, which is why I'm suggesting it for the timezone option that is supplied to the library, not necessarily for the natural language parsing (although i see no reason not to include it?)

Edit: I've made my point clear and it is being ignored, so I'm done replying.

[kimjuan]

As I said, that is not the case.

Excerpt from wikipedia:

Central European Time (CET) is a standard timet of Central, and parts of Western Europe, which is one hour ahead of Coordinated Universal Time (UTC). The time offset from UTC can be written as UTC+01:00...

As of 2023, all [member states] of the European Union observe summer time (daylight saving time), from the last Sunday in March to the last Sunday in October. States within the CET area switch to Central European Summer Time (CEST, UTC+02:00 for the summer.

It is easy to conflate "CET area" with "CET" itself.

they personally use CET to refer to the time observed...

Let me try to finish your sentence, ...in winter, after that they personally use CEST to refer to the time observed in summer.

[LJNeon]

@wanasit what are your thoughts on this? In particular handing off timezone logic to timezonecomplete (which would entirely replace dayjs).

I'm willing to open PRs for this, but would like to confirm what you want first.

[LJNeon]

Using timezonecomplete would also drastically simplify the backend of implementing repeating times, which would be very nice to have.