Support more timezone formats

[fmeringdal]

It would be nice to support more timezone formats like:

• Fixed offsets (chrono_tz::Etc::GMTMinus10 or chrono::FixedOffset can be used for this)

The only supported format atm is IANA formatted timezones.

[WhyNotHugo]

Supporting any TimeZone implementation would be ideal. A big benefit of it being a trait, is that ideally, one should be able to support any implementation from any package.

In particular I'm working on parsing VTIMEZONE from icalendar components into a VTimezone type which implements chrono::TimeZone; using these with RRULEs will obviously be necessary to fully parse icalendar components.

[WhyNotHugo]

I've been thinking about this a bit more, and one approach would be to make TimeZone completely generic everywhere in this crate, and consumers can bring-their-own-timezone:

• For my Icalendar parsing code, I'd just use my own VTimeZone implementation (I'd likely have a single instance of it for UTC and then individual instances for different timezones that I parse out of files).
• The current Tz enum could itself impl TimeZone (delegating to its inner type), and be kept under a feature flag, so that existing usages can continue working with little or no change.
• Extra methods (e.g.: name) can be defined in a TimeZoneExtras trait, which is implemented for Tz and external consumers would need to implement themselves if they use a custom timezone impl (e.g.: I'd implement it for my VTimeZone type). Some functions would just requires a TimeZone as generic parameter, while others would require TimeZoneExtras (specifically: functions that serialise and need to know the name).

Any thoughts on this?

[WhyNotHugo]

Gentle ping

[fmeringdal]

Hi @WhyNotHugo , really sorry about the delayed responses (had very little time lately) and thanks for the ping. That sounds like a valid approach which should make the library more flexible and support more use-cases.

One important aspect for me is that most shouldn't have to worry about implementing a time zone trait to use the library. I don't quite understand what you mean by feature flagging. My initial thought was that the generic could just default to rrule::TZ, which would make the generic transparent for most users while still being possible to plug in a custom implementation of time zone.

[nospam2624]

Exactly how is IANA formatted timezones defined in the context on this crate and issue?

The thing which brought me, and the core reason for phrasing the question, is that my code broke when tz-rs started to resolve Europe/Copenhagen as CEST rather than CET due to the transition into the daylight savings period. All I really wish to do is the simple use case of constructing and resolving a rrule for the current timezone.

It seems the file https://data.iana.org/time-zones/releases/tzdb-2024a.tar.lz references CEST. I lack real understanding (merely ran rgrep in the unarchived tree and obtained very similar results for CET and CEST). My hunch though is that CEST, just like(?) CET, is a valid IANA formatted timezone, and that thus rust-rrule's failure to handle it is a separate problem? Should I file a new issue, or would it just likely be a duplicate of this one for all practical purposes?

[WhyNotHugo]

@nospam2624 Icalendar files encode VTIMEZONE objects (e.g.: Europe/Copenhagen) which include the details on a timezone's offset, summer/winter offsets, and the rules for when to use one or the other.

Icalendar itself does not use IANA formatted timezones; all timezone data is included inside the icalendar component.

It's hard to give a more useful answer without knowing what you're trying to and what problem you're facing. I don't think this falls within this issue though; I'd suggest opening a new one explaining the problem thoroughly.