search

gilmoreorless / moment-timezone-data-webpack-plugin

Reduce moment-timezone data size for a webpack build
MIT License
92 stars 7 forks source link

Formatting date still works when date passed is out of date filter range #3

Closed gauravrane2212 closed 5 years ago

gauravrane2212 commented 5 years ago

I am currently exploring this webpack plugin to reduce the import size of moment-timezone library in my project. I have set the following options in my webpack config file.

new MomentLocalesPlugin(),

new MomentTimezoneDataPlugin({
  startYear: 2018,
  endYear: 2030,
}),

The reason I have this start year, is I wanted to test what would happen if I tried formatting a date which has a year before 2018 eg say 2017, 2016. (P.S. I noticed that the size of the import drastically reduced as per the documentation) However upon building the app and running it, I noticed that even though I was formatting dates with older years, it was still formatting the date correctly.

I am curious to know if this is expected or if you have seen the side effects of using the startYear or even endYear such that it doesn't correctly format the date? Do you have an example to demonstrate this.

Thanks.

gilmoreorless commented 5 years ago

The way Moment Timezone handles data means there are 2 scenarios that can happen when filtering the data:

  1. The specified time zone doesn't exist in the data:
    • This happens if you use the matchZones option of this plugin to exclude entire zones.
    • Moment Timezone will throw an error: Moment Timezone has no data for {zone name}.
  2. The time zone exists in the data, but the requested date is outside the data range (your scenario above):
    • This happens if you use the startYear and/or endYear options of this plugin.
    • Moment Timezone knows about an offset for that zone, using the nearest piece of data available, and uses that as a sort of "best guess". That means it will parse and format a date outside the range, but the offset might be incorrect for that date, depending on daylight saving rules (or any changes to the base offset).

Using your example of a date range from 2018 to 2030:

In many cases, this will accidentally give you the right UTC offset, but not always.

As an example to demonstrate... here in Sydney, my UTC offset is +10:00 by default, and +11:00 during daylight saving from October to April. Because daylight saving is active at the changeover of years, stripping out any data before 2018 will make Moment Timezone think Sydney was always +11:00 before 2018:

moment.tz('2018-07-01', 'Australia/Sydney').format()
// "2018-07-01T00:00:00+10:00" --> correct

moment.tz('2018-01-01', 'Australia/Sydney').format()
// "2018-01-01T00:00:00+11:00" --> correct

moment.tz('2017-07-01', 'Australia/Sydney').format()
// "2017-07-01T00:00:00+11:00" --> incorrect

moment.tz('2017-01-01', 'Australia/Sydney').format()
// "2017-01-01T00:00:00+11:00" --> correct, but only by accident
gauravrane2212 commented 5 years ago

Oh, this explanation helps a lot. Especially the part where you mention how the timezone offsets to the nearest piece of data.

  • Moment Timezone knows about an offset for that zone, using the nearest piece of data available, and uses that as a sort of "best guess".

Anyway, for my task, I am going to include some good amount of startYear buffer to account for this offsetting. Closing this issue.

Abraham-william commented 4 years ago

Hi All,

I am trying to test my code with PST , with years +-10 from current year, i could not find a year that fails the range, can you help