Reconsider names for TimeZoneVariant enum

[sffc]

They are currently Standard and Daylight.

The naming of "standard" is unfortunate, because it looks like something one might reach for when they need a default. In reality, this can never be defaulted, because it is the result of a TZDB calculation. Defaulting to one can produce results that are not just incomprehensible but actually wrong, like showing 8pm instead of 7pm. It is therefore our duty as API designers to prevent programmers from using Standard when they need a default value.

In Rust, we've done this in two ways:

1. Not adding a default on the enum, even when people try to add one (Add explicit defaults to FFI enums where clear-cut. #6692)
2. Typically not requiring a variant, instead allowing it to be omitted or passed as an Option

However, we should try to do better.

I think we're stuck with the status quo for 2.0, but we should consider in 3.0 whether we want to adopt new names, such as:

// Option 0: Status quo
// Pro: Consistent with US time zone naming conventions
// Con: Misleading names that are wrong for e.g. Irish Standard Time
// Con: The name "standard" sounds like it wants to be a default
pub enum TimeZoneVariant {
    Standard,
    Daylight,
}

// Option 1: Season-based
// Pro: Easy to understand; almost always correct, even in Ireland
// Con: Doesn't work in Morocco which uses Summer time year-round
//      except during Ramadan
pub enum TimeZoneVariant {
    WinterOrYearRound,
    Summer,
}

// Option 2: Offset-based
// Pro: Always correct, precisely reflects the CLDR definition
// Con: Hard to understand
pub enum TimeZoneVariant {
    LowerOffset,
    HigherOffset,
}

// Option 3: Sunrise-based
// Pro: Somewhat easy to understand
// Con: Could be confusing since sunrise in Summer is earlier than in Winter
//      despite using the LaterSunrise variant
pub enum TimeZoneVariant {
    EarlierSunrise,
    LaterSunrise,
}

// Option 4: Meridian-based
// Pro: Somewhat easy to understand
// Con: What is a meridian?
pub enum TimeZoneVariant {
    EarlierMeridian,
    LaterMeridian,
}

@robertbastian @Manishearth

[Manishearth]

I'm not actually convinced that "standard" vs "daylight" will make people reach for "standard" by default: not having a Default impl should be enough to signal that. In my PR I reached for it as a "default" mostly because every timezone is guaranteed to have a standard time, whereas it may not have a daylight time, not because I thought it was a reasonable "default".

My preference is to wait for some evidence that people are actually tripped up by this before trying to solve that problem.

---

The fact that "irish standard time" is the summer time is actually a more compelling reason for me to move away from these names, though. I also think this example is best suited to point us in the path of better naming, rather than avoiding any sense of "default".

I think a core problem here is that the "standard" and "daylight" naming is both a human-exposed naming (humans use time zone names), and an IANA technical term (S vs D, etc).

The underlying concept we are trying to represent is not "standard" vs "daylight" time, OR "summer" or "winter", it is "the baseline timezone as represented in IANA" vs "the modified timezone as represented in IANA", assuming there is a single such timezone. I don't think names talking about summer, or hour offsets, or meridians, or anything would be helpful here: the choice of baseline timezone is fundamentally an arbitrary one, as evidenced by Ireland having two different valid ways to be represented in the database.

Names like "primary" or "baseline" might help, and specifically choosing something other than "standard" gives us the opportunity to explain the nuances when people are picking this. Both of those also sound like a "default" but I actually think that's fine: the underlying concept we are representing is somewhat like a default at the IANA level, and I think it's more important to represent the concept accurately than to avoid people picking an obvious default.

[sffc]

To clarify, we are representing the CLDR and TZDB Rearguard isdst reckoning, which is "Standard is lower offset, Daylight is higher offset", which don't align with the ground truth reckoning.

We previously discussed at a fair amount of length whether we wanted to switch to TZDB Vanguard, which reflects ground truth better, but after weighing the pros and cons we decided to stick with the CLDR and TZDB Rearguard.

[Manishearth]

Oh, so it's not the "baseline" time, it's "whichever is lower". That's annoying. I think LowerOffset/HigherOffset might be good names then, even though they're kind of bland.

(maybe LowestOffset/HigherOffset? That way it makes sense for a single offset)

I'd strongly caution against names like EarlierSunrise/LaterSunrise, you have variance issues with names like that where it's unclear if they describe the transform or the state the transform is applied to: is EarlierSunrise applied for times when sunrise is earlier, or does it make sunrise happen at an earlier time?

[nekevss]

I think a core problem here is that the "standard" and "daylight" naming is both a human-exposed naming (humans use time zone names), and an IANA technical term (S vs D, etc).

Are you referring to the technical term of "savings" here or "daylight"?

I'm not entirely convinced on any of the proposed ideas above. LowestOffset/HigherOffset could make sense, but it may require documentation. What would happen if someone using data in vanguard ends up interfacing with this type?

FWIW, there was recently a brief discussion on a temporal_rs PR where this enum came up. I'm curious if Primary/Alternate could work due to the way it signals.

[robertbastian]

We previously discussed at a fair amount of length whether we wanted to switch to TZDB Vanguard

I don't recall us considering switching to vanguard, I maintain that the vanguard modeling of Ireland is stupid. What we discussed is handling vanguard tzdb outputs.

I'm not actually convinced that "standard" vs "daylight" will make people reach for "standard" by default: not having a Default impl should be enough to signal that.

+1

The fact that "irish standard time" is the summer time is actually a more compelling reason for me to move away from these names, though.

I already stated this in the PR, this problem only exists in English in the Specific Non-Location format. All other languages, and all other formats use some kind of "summer time" naming for it. I don't think this is enough of a justification to abandon this, in my opinion, very clear and understandable concept of standard/daylight.

In fact, I'm so close to proposing to CLDR to just chuck Ireland in the Western European Time metazone, because this display name cannot not confuse people on the ground.

[sffc]

What would happen if someone using data in vanguard ends up interfacing with this type?

Then they need to remap their vanguard data to rearguard data. That's exactly the objective of renaming these: it makes clear that these mean lower/higher offset and not primary/alternate.

I'm open to us adding a small data table to perform the rearguard/vanguard mapping if this becomes a common issue.

We previously discussed at a fair amount of length whether we wanted to switch to TZDB Vanguard

I don't recall us considering switching to vanguard, I maintain that the vanguard modeling of Ireland is stupid. What we discussed is handling vanguard tzdb outputs.

What I meant was that you and I decided to keep the rearguard model because neither of us thought that vanguard had any strong advantages.

I'm not actually convinced that "standard" vs "daylight" will make people reach for "standard" by default: not having a Default impl should be enough to signal that.

+1

I've already seen evidence that people can think "standard" means the "regular" time and "daylight" means the "special" time. I was also in that camp until I learned more about it. I have not done a quantitative survey, but I think if you asked people this question:

What do the "Standard" and "Daylight" time zone variants mean?

1. Standard is the regular time, Daylight is when you switch your clocks to something other than the regular time
2. Standard has a lower UTC offset (meridian occurs earlier in the day), Daylight has a higher UTC offset (meridian occurs later in the day)

you would have far more people choosing (1) than (2).

The fact that "irish standard time" is the summer time is actually a more compelling reason for me to move away from these names, though.

I already stated this in the PR, this problem only exists in English in the Specific Non-Location format. All other languages, and all other formats use some kind of "summer time" naming for it. I don't think this is enough of a justification to abandon this, in my opinion, very clear and understandable concept of standard/daylight.

In fact, I'm so close to proposing to CLDR to just chuck Ireland in the Western European Time metazone, because this display name cannot not confuse people on the ground.

Let me know if that is successful. :)

[robertbastian]

1. Standard is the regular time, Daylight is when you switch your clocks to something other than the regular time

And they'll all also know that DST means advancing the clock.

[robertbastian]

// Option 4: Meridian-based
// Pro: Somewhat easy to understand
// Con: What is a meridian?
pub enum TimeZoneVariant {
    EarlierMeridian,
    LaterMeridian,
}

I don't think "meridian" is the term you're looking for. A meridian is a great circle connecting the poles, which cannot be "early" or "late". You probably want to say "mean solar noon" (which "meridian" apparently used to mean until the 19th century (Wiktionary), but this predates timezones).