Luxon – A library for working with dates and times in JS • Hacker News Board

Re: Luxon – A library for working with dates and times in JS

#51

Post by sd8dgf8ds8g8dsg » Sun, Nov 19, 2017, 6:38 AM UTC

seanp2k2 wrote: post #49

collectively wrote: post #46

Earlier quoted context omitted.

At some point, a kilobyte was 1024 bytes. Now, a kilobyte is 1000 bytes, and 1024 bytes is a kibibyte. I mean, it does make sense. But it just sounds off to me.

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

Re: Luxon – A library for working with dates and times in JS

#52

Post by frutiger » Sun, Nov 19, 2017, 7:00 AM UTC

hectorlorenzo wrote: post #15

bshimmin wrote: post #14

Months 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.

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 - 1900 */
            int tm_wday;   /* Day of the week (0-6, Sunday = 0) */
            int tm_yday;   /* Day in the year (0-365, 1 Jan = 0) */
            int tm_isdst;  /* Daylight saving time */
        };

Also, it allows you to do things like

    ["JAN", "FEB", ..., "DEC"][theDate.month]

Re: Luxon – A library for working with dates and times in JS

#53

Post by hectorlorenzo » Sun, Nov 19, 2017, 7:15 AM UTC

icambron wrote: post #37

hectorlorenzo wrote: post #15

Earlier 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.

No, they're 0-indexed in Moment. But yes, the reason I made Luxon 1-index them is that days and years are 1-indexed. I also fielded a lot of issues in Moment that were caused by newer programmers not knowing that months were 0-indexed.

Good stuff.

Re: Luxon – A library for working with dates and times in JS

#54

Post by pitaj » Sun, Nov 19, 2017, 7:22 AM UTC

seanp2k2 wrote: post #48

pitaj wrote: post #30

Earlier 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.

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.

Re: Luxon – A library for working with dates and times in JS

#55

Post by BrandoElFollito » Sun, Nov 19, 2017, 7:41 AM UTC

seanp2k2 wrote: post #47

icambron wrote: post #40

Luxon author here, happy to answer anything. Edit: Here's a thing I wrote about why this exists: https://moment.github.io/luxon/docs/manual/faq/why.html

When can you make a Python version available? Datetime is by far my biggest gripe with Python. It takes many times the lines of code to do something “simple” with it vs other languages (e.g. parse remote time stamp in a specific format, apppend time zone info to that, get local time + zone, normalize both to UTC, compare, present difference in human-readable format). Here’s the python version of moment: https://githu…

Have you tried arrow (my favorite), dolorean or a third one the name escapes me right now?

I use arrow whenever I need to process a date, no matter the usage. Having a consistent interface is golden.

EDIT I just realized that the author of moment in Python (you link to) also mentions arrow. I have to remember the name of the third package, it addressed some weaknesses in arrow (particularly issues with failed parsing which does not output an error)

Re: Luxon – A library for working with dates and times in JS

#56

Post by gjjrfcbugxbhf » Sun, Nov 19, 2017, 7:44 AM UTC

seanp2k2 wrote: post #48

pitaj wrote: post #30

Earlier 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.

Why epoch over UTC?

Re: Luxon – A library for working with dates and times in JS

#57

Post by dwg » Sun, Nov 19, 2017, 7:51 AM UTC

bshimmin wrote: post #14

Months 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.

As explained on the website, that's why this is Luxon and not moment 3.0. It's a great approach for them to take that allows them to experiment, grow, and relieve the pressure from calls for change, without disrupting the existing community.

Re: Luxon – A library for working with dates and times in JS

#58

Post by dwg » Sun, Nov 19, 2017, 7:54 AM UTC

bastijn wrote: post #2

Not a direct js dev so forgive my ignorance. How does this compare to moment.js [0]? Any feature differences? [0] https://momentjs.com/

For me and I'm sure others one of the most important differences is immutability. This has been a big request from the community, but would be impossible to implement in moment without breaking much code which relies on the current mutability.

https://github.com/moment/moment/issues/1754

Re: Luxon – A library for working with dates and times in JS

#59

Post by collectively » Sun, Nov 19, 2017, 8:11 AM UTC

sd8dgf8ds8g8dsg wrote: post #51

seanp2k2 wrote: post #49

Earlier 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

Well to be fair “GB” could refer to either prefix.

Re: Luxon – A library for working with dates and times in JS

#60

Post by CodesInChaos » Sun, Nov 19, 2017, 9:55 AM UTC

seanp2k2 wrote: post #48

pitaj wrote: post #30

Earlier 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.

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.