timezone in milliseconds

[flip111]

Would it be ok to add a function to get the timezone in milliseconds? Because DateTime is also milliseconds based so why shouldn't the timezone.

https://github.com/date-fns/date-fns/blob/16c529508a323d78f70b91209ebf043f3c09671d/src/_lib/getTimezoneOffsetInMilliseconds/index.ts#L12

[garyb]

I don't think we need a dedicated function for it since it's just Now.getTimezoneOffset <$> Duration.fromDuration.

[flip111]

You will still have minute resolution (multiples of 60000 milliseconds). JS has much lower resolution available https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/now#reduced_time_precision

The getTimezoneOffset() method of Date instances returns the difference, in minutes, between this date as evaluated in the UTC time zone, and the same date as evaluated in the local time zone.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/getTimezoneOffset

[garyb]

Do you know of a timezone offset that is not a multiple of 15 minutes? I can't imagine milliseconds precision is actually needed?

[flip111]

There is an example in the comments of the code of the first link.

[garyb]

Ah I see... man I hate time 😆.

I'm still not sure if we need it, since you can only get the timezone offset for the current locale at the current time, which wouldn't fall foul of that.

We don't generally deal with timezones at all, purescript-datetime doesn't have a non-UTC representation and has no logic for dealing with timezones, because nobody has the time/energy/inclination to have it deal with the necessary special cases and keep it up to date with tzdata.

I'm not saying we can't add this, just not sure how much value it would have in this library, perhaps would be more useful in js-date since you could use it as date -> offset there?

If we do add it here we may as well update getTimezoneOffset to use the more precise implementation too, since it durations like Minutes can be fractional.

[flip111]

since you can only get the timezone offset for the current locale at the current time, which wouldn't fall foul of that.

I'm also not aware of a 2023 timezone with sub-minute resolution. But that's because i can't be bothered to look into tzdata and keep an eye on it in the future.

We don't generally deal with timezones at all

It's necessary when you want to print the datetime to the user in their local time.

in this library

It shouldn't be a function taking an argument but rather comparing to a freshly constructed Date representing time in current locale.

how much value it would have

I also find it a bit questionable, but i don't really see a downside to it either. I just thought it was cool that other libraries pick up on the higher resolution that the browser provides.