Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New Features in ES2019

javascript.christmas

Post reply on HN
Print view View original

101–110 of 123 posts

Re: New Features in ES2019

#101

Post by manigandham »

sixbrx wrote: post #99
manigandham wrote: post #21

Earlier quoted context omitted.

You can use an unix epoch (seconds or milliseconds from 1/1/1970) to make parsing very fast. This is naturally supported by Javascripts new Date() too.

its ok for instants but not dates: receiving side may truncate the instant to a date in a different timezone env than the sender (easily done and will NOT be UTC by default in many envs) -and then you may have an off-by-one on the day.

Unix epoch by definition is UTC. An instant can be converted properly to any timezone without issue.

Re: New Features in ES2019

#102

Post by lightgreen »

mantap wrote: post #28
pythux wrote: post #11

Really liking these new developments! JavaScript is not the horrible language it used to be anymore (in my very subjective opinion). When I started writing JavaScript in 2016 after a Python background I was frustrated every day... Then after some time and learning about which dark corners to avoid, which tools to use, etc. it became quite an enjoyable experience. Nowadays I mostly use a mix of JavaScript and TypeScri…

The difference between JS and C++ is that C++ is addressing a complex problem domain whereas JS is addressing a simple one. So JS can put its complexity budget towards features that improve productivity whereas such features in C++ require huge amounts of complexity. Take for instance anonymous functions in JS compared with lambdas since C++11, the C++ version needs a complicated capture syntax, capability for captur…

> C++ version needs a complicated capture syntax

C++ doesn't actually need it. Rust proved that capture everything by reference or capture everything by move is enough for all practical use cases.

C++ lambdas is another example where C++ committee chose complex uber-universal solution instead of much simpler which solves 99% use cases.

Re: New Features in ES2019

#103

Post by paulddraper »

dwaltrip wrote: post #92
paulddraper wrote: post #86

Earlier quoted context omitted.

Why have a JSON number? Why not "just stick with" decimal strings?

I see your point, but numbers are easier to standardize than dates, so there is some logic to drawing the line there. It has to be drawn somewhere.

> numbers are easier to standardize than dates

Is this a joke?

JSON numbers are....I don't know what they even are. JavaScript -- the originator of JSON -- can't support 64-bit integers in JSON. Nor can it support decimal fractions in JSON, despite JSON using decimals. And yet JSON numbers also aren'ty IEEE-754 floating point numbers, as they lack +/-Infinity and NaN.

JSON numbers are ill-defined and unique from every other "number" concept in any language or format.

Re: New Features in ES2019

#104

Post by BillinghamJ »

goto11 wrote: post #72
BillinghamJ wrote: post #17

Earlier quoted context omitted.

There's plenty of good reasons one doesn't exist. JSON is not JS-specific. It is a standard interchange format used by thousands of languages, many of which have very different date implementations. If you did have a JSON date, how would you decide what it was? Would it be a timestamp, or a civil date-time? Would it have timezones? Offsets? Locations? Would there be a database along with it required to understand it…

That is not a good reason though. The spec could just decide on the wire format like with strings and numbers, and clients would have to translate into the date type of the language or platform. The reason JSON doesn't have dates is simply because JavaScript doesn't have date literals. You can write new Date(...) in JavaScript, but allowing that in JSON would have opened a whole can of worms.

JSON started already having incompatibilities with JS literals - JS objects are only just being made a superset of JSON in ES2019

Re: New Features in ES2019

#105

Post by BillinghamJ »

ryanbrunner wrote: post #26
BillinghamJ wrote: post #17

Earlier quoted context omitted.

There's plenty of good reasons one doesn't exist. JSON is not JS-specific. It is a standard interchange format used by thousands of languages, many of which have very different date implementations. If you did have a JSON date, how would you decide what it was? Would it be a timestamp, or a civil date-time? Would it have timezones? Offsets? Locations? Would there be a database along with it required to understand it…

A 'date' type could be as simple as syntax indicating that a particular ISO8601 string IS a date. Right now, there's no reasonable way to infer that unless you're already aware of the schema of the JSON object you're receiving. You could make the same argument with numbers - there's no reason you couldn't just pass strings containing the number - but there's advantages to being able to distinguish between a string an…

If you're not aware of the schema, how would you use the value? Same as any other use of strings - enums, types, etc

Re: New Features in ES2019

#106

Post by sixbrx »

manigandham wrote: post #101
sixbrx wrote: post #99

Earlier quoted context omitted.

its ok for instants but not dates: receiving side may truncate the instant to a date in a different timezone env than the sender (easily done and will NOT be UTC by default in many envs) -and then you may have an off-by-one on the day.

Unix epoch by definition is UTC. An instant can be converted properly to any timezone without issue.

That's not the point, the point is an instant is not a date. And common ways of getting the date from an instant are likely to give you the date of the instant interpreted in your current timezone for your computing env (which is often what is wanted such as when displaying for a user), so when you extract the date portion, it is not the intended one. So it's not that there's an easy right way of doing it, of course there is - but there are also easy wrong ways which also seem obvious.

Also, forget about the receiving side, you're also assuming that the sending side meant the date for the instant as at offset 0 instead of in their own timezone (which is probably how the instant is being displayed for them). From experience, that's not a safe assumption - witness any instant meant to mean "today's date here and now" derived from a now() call alone or truncated to have 0 time parts (in current time zone!) - I see that attempted a lot. Way too error prone especially when you don't control both sides.

Re: New Features in ES2019

#107

Post by burpsnard »

chrismorgan wrote: post #42
masklinn wrote: post #38

Earlier quoted context omitted.

You're misreading the article section, although the article is also partially wrong: the old behaviour was to output the lone surrogate in the JSON stream[0] (the "�" here is confusing: it is a display artefact of the specific font, not U+FFFD), the new behaviour is to replace the unpaired surrogate by the literal 6-character long escaped representation of the unpaired surrogate . That is, formerly U+D83D would pass…

Ah, you’re right; thanks for the correction. The article does contain an error here, for the code point on the page is actually U+FFFD, not U+D83D (which of course is unrepresentable there). I trusted that (being a little surprised that it’d do the replacement, which is more what I’d expect of Python, but accepting it all the same) and didn’t pull out an old browser to confirm what actually happens, which is, as you…

I'm suddenly reminded of the hours i spent noodling around with sgml.xml entity catalogues (™ © etc)

Re: New Features in ES2019

#108

Post by manigandham »

sixbrx wrote: post #106
manigandham wrote: post #101

Earlier quoted context omitted.

Unix epoch by definition is UTC. An instant can be converted properly to any timezone without issue.

That's not the point, the point is an instant is not a date. And common ways of getting the date from an instant are likely to give you the date of the instant interpreted in your current timezone for your computing env (which is often what is wanted such as when displaying for a user), so when you extract the date portion, it is not the intended one. So it's not that there's an easy right way of doing it, of course…

Yes it is. An instant expressed as a Unix epoch is a date in UTC. The sender converts any non-UTC date to UTC and then to unix time. The receiver parses unix time to a UTC date, and then converts to any timezone necessary. What's the problem?

If you're using code that doesn't know how to handle UTC or converts it automatically to some server/env timezone, or doesn't check the timezone of the dates then that's a problem with that code, and has nothing to do with JSON or unix time.

Re: New Features in ES2019

#110

Post by haecceity »

wging wrote: post #59
haecceity wrote: post #4

I wonder what kind of shenanigans you could do with Function.toString(). It'd be even better if they had Function.toAST().

Lots. I can't remember exactly what I've seen, but believe I have seen it used in interesting ways. Including (drum roll...) .toString().substring(some_magic_number, ...) to do something or other (wish I remembered what). I'll let you think about whether that's wise, but note that indexing into 'function /* a comment */ foo () {}' (the example from the article) will give different results from indexing into 'function…

It'd be less magical if you could manipulate the AST instead of the code as a string.
Post reply on HN