Stop depending on is_dst for calculations
#356
Conversation
jedel1043
added
C-api
| #[derive(Debug, Clone, Copy, PartialEq, Eq)] | ||
| pub struct TimeZoneOffset { | ||
| pub struct UtcOffsetSeconds(pub i64); |
There was a problem hiding this comment.
praise: yeah, this is a better name
| // Note(nekevss): it may be best to switch this to initial, need to double check | ||
| // disambiguation ops with inverse DST-STD relationship | ||
| Ambiguous { | ||
| std: LocalTimeRecord, | ||
| dst: LocalTimeRecord, | ||
| std: UtcOffsetSeconds, |
There was a problem hiding this comment.
thought: maybe these should be changed from std/dst to standard/savings
General thought is to move away from the day light savings time reference. So savings is the offset that "saves" time so to speak. That may be incorrect though too because standard / savings might be a bit incorrect here (thinking mostly about dublin)
There was a problem hiding this comment.
Maybe standard and alternate then? It removes the "savings" terminology for something more general: an "alternate" timezone a region uses
There was a problem hiding this comment.
I think my only concern would be that it's not so much an alternate as it is a secondary. Weirdly enough the only good term I can think of is savings (but that's after working on all of the zoneinfo stuff).
I think icu_time uses VariantOffsets and they use standard and daylight.
There was a problem hiding this comment.
Hmm yeah, maybe this requires a bigger discussion on how to name timezone things. I'll merge this in the meantime and we can have a names discussion before releasing 0.1
Makes it so that our timezone calculations don't depend on the
is_dstfield to calculate if a datetime is within a forward transition.I think this is a breaking change, but because the timezone providers are unstable, it should be fine.