There seems to be a bug in getUnixTime. The unix timestamp is incorrectly generated just after the change to PDT.

I've validated the result and compared the behavior to moment-timezone. See test case below

const moment = require('moment-timezone');
const { findTimeZone, getUnixTime } = require('timezone-support');

const unix1 = getUnixTime(
  { year: 2018, month: 3, day: 11, hours: 5 },
  findTimeZone('America/Vancouver')
) / 1000;
console.log(unix1);
// => 1520773200
// => 1520773200 converts to Sunday March 11, 2018 06:00:00 (am) in time zone America/Vancouver (PDT)
// Reference: https://www.epochconverter.com/timezones?q=1520773200&tz=America%2FVancouver

const unix2 = moment.tz('2018-03-11T05:00:00', 'America/Vancouver').unix();
console.log(unix2);
// => 1520769600
// => 1520769600 converts to Sunday March 11, 2018 05:00:00 (am) in time zone America/Vancouver (PDT)
// Reference: https://www.epochconverter.com/timezones?q=1520769600&tz=America%2FVancouver

Would be great if this could be fixed. It has caused me some headaches as I'm trying to improve performance by migrating from moment-timezone to timezone-support.

Thank you very much for your consideration!

ES6 imports are natively supported in all major browsers it would be really convenient to have published packages to include ESM support.

Hi.
In readme it's said:

Tiny code base - 4.6 KB minified, 1.7 KB gzipped...

In my project I see different picture:

I use it via date-fns-timezone: ^0.1.4

Hi!

Does this library takes DST adjustments into consideration?

Take this case for example:

At 00:00 of 1/3/2024 in some timezone T, the clocks will move forward one hour. If I ask what is the Date corresponding to 00:30 of 1/3/2024 at timezone T, will the library say that this is not defined?

There is another case, which is when the clocks move backward one hour, in which the library should say that the conversion is ambiguous.

This is what happen with e.g. this C++ date library

What will happen in these cases with this library?

Thanks!

Would you accept a PR that includes the well-known time zone name and abbreviation in each zone as listed here: https://www.timeanddate.com/time/zones/?

convertToTimeZone(parsedDate, { timeZone: timeZone.name })

It would allow a caller to use the following format: convertToTimeZone(new Date(), { timeZone: 'Eastern Standard Time' })

moment-timezone has a 9KB, 2012-2022 subset version of the data, instead of full 25KB one. Having something similar here would be really useful.

Also, the dates at https://github.com/prantlf/timezone-support#release-history should be 2019

Are those interfaces really considered private? If so then why some public functions use them as return and/or input types?

For now I need to use "any" or redefine the interfaces in my own code, which doesn't seem right.

Since the project seems to be abandoned, a fork would be needed to use the latest data. Creating this issue to compile information regarding data generation. Timezone info is stored in /util/data folder in json format, but it isn't clear to me how is it generated from the official IANA dataset. Any idea?

Doesn't work in IE.
When i'm using findTimeZone i got an error because imported module not in ES5 format.

Could you check please ?

When trying to use the example below from the documentation in a create-react-app.
Issues:
-The example provided in the documentation is not working
-There is a parsing error?
**Provided is a picture of the error, and a code sandbox example **

const { parseZonedTime } = require('timezone-support/dist/parse-format')
const input = '2.9.2018 10:00 CEST+02:00'
const format = 'D.M YYYY H:mm:ss [z]Z'
const time = parseZonedTime(input, format)

Please refer to the following code sandbox to take a look at the error.

https://codesandbox.io/s/notworking-mdsnh

I found this problem when profiling our application code. attachEpoch comes up quite clearly as at the top suspect for slow down. Interestingly when I looked at setTimeZone the zone property is added via assignment and it's only the epoch property that is added via defineProperty. Is it possible to change attachEpoch to add epoch via assignment?

Adding property through assignment is 2 orders of magnitude faster (see https://jsperf.com/object-defineproperty-vs-assignment/3)

First of all, thanks for the work.

Many users expect something more usable, e.g. Pacific Time, rather than "America/Los_Angeles". Is it possible to infer such information?

Node.js Package: commander versions up to and including 8.3.0 have reached their end of life. https://github.com/tj/commander.js/security

So we need to upgrade it to use most stable version to pass security check

+-- [email protected]
| -- [email protected] | -- [email protected] deduped

There seems to be no changes since 1.5 years ago, no replies on issues or pull requests. I reached out to all contributors on email and didn't get any replies.

type DateInput
interface TimeZoneInfo
interface TimeZoneOffset
interface Time
interface SetTimeZoneOptions

are all not exported alongside the functions like findTimeZone and setTimeZone

This leads to that you have to create your own interfaces that mirror them (problematic on version update when the interface changes).
Would love to create a PR to export the types and interfaces as well.

Let me know what you think

Are these within the scope of the project?

https://en.wikipedia.org/wiki/List_of_time_zone_abbreviations

I'm looking for a library to parse things like EST or MET.

Is it possible to add a filter on the returned list, so that the deprecated timezones are not included?

in package.json

  "main": "dist/index.js",
  "typings": "dist/index.d.ts",

however typings seem to have moved to src/index.d.ts ? Or weren't published to dist/ for some reason

Please could you republish it?
https://www.npmjs.com/package/timezone-support/v/1.8.1

I'm in the process of optimizing the JavaScript bundle size for my company's application. The 'timezone-support' package seems to be significantly contributing to the size. In my codebase, there's a particular file where the following lines need refactoring:

const { getZonedTime, findTimeZone } = require('timezone-support');
const { formatZonedTime } = require('timezone-support/dist/parse-format');

Given that 'timezone-support' is now updated to version 3 or above, I'm looking for the most efficient method to import formatZonedTime without having to load the complete 1MB+ distribution of 'timezone-support'.

Most timezones don't seem to work other than (what I figured out after a short test) GMT, UTC, or EST but the timezone CST doesn't work and responds with Error: Unknown time zone "CST".. This occurs when trying to use the findTimeZone method. Is there any explanations as to why this is happening?

description

please check https://runkit.com/xiechao06/5c612729324f18001270d413

why

I think it is a little convenient to get the 0 o'clock of a certain date and inconsistent, why seconds and milliseconds default to 0?

suggestion

I think if hours/minutes are lacked, they should default to 0

Hi, just browsing here randomly and noticed you have a private token visible in your public repo, in .coveralls.yml

I don't know if this is by (lazy) design, but it's bad security practice, so just letting you know 😄

When using "module": "node16" TypeScript is unable to find the typings for the package.

Could not find a declaration file for module 'timezone-support'. 'foo/node_modules/timezone-support/dist/index.mjs' implicitly has an 'any' type.

Since the file imported is dist/index.mjs, TypeScript looks for a dist/index.d.mts file which doesn't exist.

Hello and Happy 2023 🥳

I noticed that there are smaller bundles made so that we don't pack too much data when using timezone-support.
The smallest one is 2012-2022. Do you plan to release a new one since 2022 is gone. (Could be 2023-2033 or something else) ?

I could create a PR, but before, I'd like to validate that it would make sense for timezone-support