Mismatched data

[BehindTheMath]

It looks like for many of the timezones, the value and text properties reflect the values for standard time, whereas the abbr and offset properties refect the values for DST.

For example, for Eastern Standard Time, value === 'Eastern Standard Time' and text has an offset of UTC-05:00, which are the correct values for standard time. However, offset === -4, and abbr === 'EDT', which stands for Eastern Daylight Time.

[dmfilipenko]

@BehindTheMath fell free to make pull request

[manojeltropy]

PST is "pacific standard time" but here it says "pakistan standard Time"

[hexadecy]

When isdst=true, abbr and offset follow. In my use case, I only use Text and utc[0] = "America/Detroit". I use the TZ database to do the rest.

[hexadecy]

pakistan standard Time should be PKT

[hexadecy]

I think it should have been abbr_dst and offset_dst. But this is a breaking change.

[BehindTheMath]

@dmfilipenko How about if we would change the format to something like this:

interface TimezoneDetails {
  value: string;
  abbr: string;
  offset: number;
  text: string;
}
export interface Timezone extends TimezoneDetails {
  dst: TimezoneDetails | false | null;
  utc: string[];
}

Here's an example of what it would look like:

  {
    "value": "Eastern Standard Time",
    "abbr": "EST",
    "offset": -5,
    "text": "(UTC-05:00) Eastern Time (US & Canada)",
    "dst": {
      "value": "Eastern Daylight Time",
      "abbr": "EDT",
      "offset": -4,
      "text": "(UTC-04:00) Eastern Time (US & Canada)",
    },
    "utc": [
      "America/Detroit",
      "America/Havana",
      "America/Indiana/Petersburg",
      "America/Indiana/Vincennes",
      "America/Indiana/Winamac",
      "America/Iqaluit",
      "America/Kentucky/Monticello",
      "America/Louisville",
      "America/Montreal",
      "America/Nassau",
      "America/New_York",
      "America/Nipigon",
      "America/Pangnirtung",
      "America/Port-au-Prince",
      "America/Thunder_Bay",
      "America/Toronto",
      "EST5EDT",
    ],
  },
  {
    "value": "Venezuela Standard Time",
    "abbr": "VST",
    "offset": -4.5,
    "text": "(UTC-04:30) Caracas",
    "dst": false,
    "utc": [
      "America/Caracas",
    ],
  },

The value, abbr, offset, and text properties would be in the root object for standard time, and again as properties of the dst property if applicable.

This would be a breaking change, and would require a major version bump.

[dmfilipenko]

@BehindTheMath This is a huge change. Unfortunately, I don't have much time to do this

[BehindTheMath]

I might do it myself and submit a PR.

What do you think of such a schema?

[dmfilipenko]

@BehindTheMath from a first view it might be useful. But what if we wouldn't make a nested object and add another timezone

{
    "value": "Eastern Daylight Time",
    "abbr": "EDT",
    "offset": -4,
    "dst": true,
    "text": "(UTC-04:00) Eastern Time (US & Canada)",
    ...
},
{
    "value": "Eastern Standard Time",
    "abbr": "EST",
    "offset": -5,
    "text": "(UTC-05:00) Eastern Time (US & Canada)",
    "dst": false,
    ...
}

I prefer to left this structure a flat

[BehindTheMath]

@dmfilipenko My issue with that way is that there's no relationship between standard and daylight timezones. So if I have one, there's no easy way to get the other.

[dmfilipenko]

@BehindTheMath I was thinking about and seemed like it is reasonable. Lets try to do this

[mikeyyyzhao]

@BehindTheMath any progress on this? This is so close to what we need

[BehindTheMath]

I kind of gave up on it and started using Luxon instead.