2017. We have async, promises, classes, => functions in Javascript, but we still have abysmal date & time support and 100 libraries to solve it.
This library looks less bad than momentJS' tangled ball of mud. Good job
Luxon – A library for working with dates and times in JS
61–70 of 80 posts
Re: Luxon – A library for working with dates and times in JS
#62Earlier quoted context omitted.
Hard drive manufacturers have been doing this for decades. This is why the “80GB” drives were 74.5GB in Windows. It’s more complicated with SSDs: https://www.anandtech.com/show/2829/7 EDIT: the official “kibibyte” was standardized in 1998: https://physics.nist.gov/cuu/Units/binary.html so almost 20 years ago. Blame Windows and HDD mfgs for sticking with the SI definitions.
Yea, bad bad windows for following standards. The SI prefixes are well established before 1998 and the cause for this brainmelt. https://en.wikipedia.org/wiki/Metric_prefix
Windows (at least up to 8) does not follow the SI standard. It uses KB, MB, GB but converts using 1024. Which has funny consequences, like 999MB being smaller 0.94GB.
Re: Luxon – A library for working with dates and times in JS
#63Months in Luxon are 1-indexed instead of 0-indexed like in Moment and the native Date type. This seems like a bold decision and terrifying source of errors for those of us with decades of experience thinking January is 0.
No, Javascript is the terrifying source of errors here.
Re: Luxon – A library for working with dates and times in JS
#64PLEASE use joda-js on Javascript: https://js-joda.github.io/js-joda/ It's a port of the java8 date/time API, which is the most correct date-handling library there is.
Oh this one looks nice! Documentation looks like someone actually thought about it
Re: Luxon – A library for working with dates and times in JS
#65Earlier quoted context omitted.
I think that moment.js was already built that way. For me it kinda makes sense: if days are calculated with a 1-index in mind, why make months different? As I said: it KINDA makes sense.
I'm not defending the difference between how months and days/years are treated. But here are some possible reasons. From ctime(3): Broken-down time is stored in the structure tm, which is defined in as follows: struct tm { int tm_sec; /* Seconds (0-60) */ int tm_min; /* Minutes (0-59) */ int tm_hour; /* Hours (0-23) */ int tm_mday; /* Day of the month (1-31) */ int tm_mon; /* Month (0-11) */ int tm_year; /* Year - 19…
Well, nobody is confused when their digital watch reads "00:00:00" as the ball drops on New Years Eve. But if the date was 2018-00-01 people would be like "WTF??"
Re: Luxon – A library for working with dates and times in JS
#66So it's a better moment made by the moment team: https://moment.github.io/luxon/docs/manual/faq/moment.html Major differences: * Immutable * Months in Luxon are 1-indexed instead of 0-indexed like in Moment and the native Date type. * Localizations and time zones are implemented by the native Intl API (or a polyfill of it), instead of by the library itself. * Luxon has both a Duration type and an Interval type. The I…
In what situation is immutable important?
Re: Luxon – A library for working with dates and times in JS
#67Earlier quoted context omitted.
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`
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.
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.
Re: Luxon – A library for working with dates and times in JS
#68So it's a better moment made by the moment team: https://moment.github.io/luxon/docs/manual/faq/moment.html Major differences: * Immutable * Months in Luxon are 1-indexed instead of 0-indexed like in Moment and the native Date type. * Localizations and time zones are implemented by the native Intl API (or a polyfill of it), instead of by the library itself. * Luxon has both a Duration type and an Interval type. The I…
In what situation is immutable important?
Dates and times are values by definition, not mutable objects that can be changed via methods. The year 2017 is 2017. It represent a moment in time, or more precisely a period of time between two points. The year 2017 does not “become” 2018 when you .add one year to it. Fully immutable objects are also easier and simpler to compare since they are, again, values. 2017 is 2017, always. Not using proper immutability leads to an “object identity” crisis where everything is anything. An infinite amount of years 2017 are allowed to exist by default(!) and they are not easily comparable or require specific library APIs to allow that.
Re: Luxon – A library for working with dates and times in JS
#69Earlier quoted context omitted.
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`
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.
> 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
Re: Luxon – A library for working with dates and times in JS
#70Ah, immutable. Mutability is my biggest issue with Moment.js. It seems they have kept the API mostly the same, so this will be easy to replace.