5 ms·

If you only want timezone conversions I removed everything else from Moment. It's less than 2KB uncompressed: https://github.com/scorredoira/timezone.js https:/

If you only want timezone conversions I removed everything else from Moment. It's less than 2KB uncompressed: https://github.com/scorredoira/timezone.js https://github.com/scorredoira/timezone.js

pitaj 9y ago
I my experience the actual timezone information is the heaviest portion of the payload. I can't wait until all browsers have support for `Intl`
- seanp2k2 9y ago
  That any computers talk to each other about time in any other terms than epoch is insane to me. From there, converting it to local time zone is pretty easy, but it should be a presentation-layer ONLY thing. If you’ve ever worked with or implemented a system where this wouldn’t work, I’m interested in hearing about why.
  - pitaj 9y ago
    Ah, sorry. I was speaking more in terms of internationalization than actually converting between time zones. All you need is a database, but that database can be hard to maintain and can be very large.
  - gjjrfcbugxbhf 9y ago
    Why epoch over UTC?
  - CodesInChaos 9y ago
    If you schedule a meeting in the future you typically agree on a local time in a specific timezone. So the (local time, timezone) tuple is the authoritative value you want to store (you can cache the utc time if you want). Just storing the utc time and timezone is problematic, since the conversion function between utc and local can change via tz database updates, sometimes with little notice (Israel is notorious for sometimes only deciding on the DST switching date shortly before it happens). In principle you could store (utc-time, offset used to convert from local, timezone), but I find that rather unintuitive and error prone, since it doesn't cleanly separate authoritative from cached values.
  - icambron 9y ago
    Ideally, yes. There are a lot of times you need it though: 1. Recurring meeting events have to take place in a certain zone so that the right epoch time can be calculated for the recurrences across DSTs 2. Even single meetings need them (see other post in this thread) 3. You may need other zone's local times. Imagine you're scheduling shifts for people to work. If you're in a different zone than work is scheduled in, the presentation later needs to know that zone to compute the right epoch times.
  - dmitriid 9y ago
    > That any computers talk to each other about time in any other terms than epoch is insane to me. Year 2038 problem: https://en.wikipedia.org/wiki/Year_2038_problem https://en.wikipedia.org/wiki/Year_2038_problem
  - alphaalpha101 9y ago
    That anyone uses UTC for anything where it isn't relevant is insane to me. If I schedule a meeting in local time, then it's in local time. It has nothing to do with UTC. It's local time at the beginning, middle and end.

If you only want timezone conversions I removed everything else from Moment. It's less than 2KB uncompressed: https://github.com/scorredoira/timezone.js https://github.com/scorredoira/timezone.js

pitaj 9y ago

I my experience the actual timezone information is the heaviest portion of the payload. I can't wait until all browsers have support for `Intl`

seanp2k2 9y ago
That any computers talk to each other about time in any other terms than epoch is insane to me. From there, converting it to local time zone is pretty easy, but it should be a presentation-layer ONLY thing. If you’ve ever worked with or implemented a system where this wouldn’t work, I’m interested in hearing about why.
- pitaj 9y ago
  Ah, sorry. I was speaking more in terms of internationalization than actually converting between time zones. All you need is a database, but that database can be hard to maintain and can be very large.
- gjjrfcbugxbhf 9y ago
  Why epoch over UTC?
- CodesInChaos 9y ago
  If you schedule a meeting in the future you typically agree on a local time in a specific timezone. So the (local time, timezone) tuple is the authoritative value you want to store (you can cache the utc time if you want). Just storing the utc time and timezone is problematic, since the conversion function between utc and local can change via tz database updates, sometimes with little notice (Israel is notorious for sometimes only deciding on the DST switching date shortly before it happens). In principle you could store (utc-time, offset used to convert from local, timezone), but I find that rather unintuitive and error prone, since it doesn't cleanly separate authoritative from cached values.
- icambron 9y ago
  Ideally, yes. There are a lot of times you need it though: 1. Recurring meeting events have to take place in a certain zone so that the right epoch time can be calculated for the recurrences across DSTs 2. Even single meetings need them (see other post in this thread) 3. You may need other zone's local times. Imagine you're scheduling shifts for people to work. If you're in a different zone than work is scheduled in, the presentation later needs to know that zone to compute the right epoch times.
- dmitriid 9y ago
  > That any computers talk to each other about time in any other terms than epoch is insane to me. Year 2038 problem: https://en.wikipedia.org/wiki/Year_2038_problem https://en.wikipedia.org/wiki/Year_2038_problem
- alphaalpha101 9y ago
  That anyone uses UTC for anything where it isn't relevant is insane to me. If I schedule a meeting in local time, then it's in local time. It has nothing to do with UTC. It's local time at the beginning, middle and end.