Current Offset vs Raw Offset

[Joel P]

I see you switched to using the current offset instead of the January offset. However, I think for most of my users, the raw offset is more recognizable. Perhaps the generated json could include both currentFormat and rawFormat/januaryFormat.

Additionally, it would be helpful to have the raw and current offset included in the json object.

[Joel P]

On second thought, one downside of setting the formatted output to the current date ZZ is it'll regularly change even when the geonames data is unchanged. For this reason, I think it would be better to have formatted consistently use the raw offset (which most people know, I think), and include the DST offset as an additional property for users that want to display that in their apps.

[Vincent Voyer]

Hey there, thanks for opening the issue, you're my first real user I guess! :)

I see you switched to using the current offset instead of the January offset

Indeed, the offset timing (+02:00) is always the current one while the offset name/abbreviation is always the January one (without DST etc..).

However, I think for most of my users, the raw offset is more recognizable
Additionally, it would be helpful to have the raw and current offset included in the json object.
one downside of setting the formatted output to the current date ZZ is it'll regularly change even when the geonames data is unchanged

I have been thinking about this too.
First, the reason why I am using the current offset is because .. It's what google does, see:

(This is google calendar).

Now, this is a personal choice (displaying current DST offset) and it may or may not be relevant to you. For example in my application, under the time zone selector, I added "DST is automatically handled".

As for including the computed DST offset (current or January one) as a key or inside formatted, I even considered not doing it at all. Because on the day of DST update, this library will be updated yes, but the time it will take to people to update the lib and deploy to production, all DST offsets will be wrong in their application. So ideally DST offsets should be computed at runtime, not build time.

That's why I was even thinking NOT to include them and show in the README how to map() over the timezones and add the DST to the formatted structure by using the timezone.name directly.

What do you think?

[Joel P]

I agree on the lag problem. DST effective dates are so arbitrary that it doesn't make sense in my mind to make the output dependent on that. I recommend including the DST offset as additional data, and making Formatted be as consistent as possible year round. If users want to show the DST offset instead of the raw offset, they can build their own format string. To that end, I would also recommend including the raw offset for those users who may want to customize the format in other ways (e.g. include only one city instead of two, etc.)

Suggested json object

{
  name: "",
  alternativeName: "",
  mainCities: [],
  group: [],
  offsetRaw: 0, // or does this need to be a string?
  offsetDst: 0,
  formatted: ""
}

[Vincent Voyer]

🎉 This issue has been resolved in version 4.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀