元スレ+ JavaScript の質問用スレッド vol.137 +
JavaScript覧 / PC版 /みんなの評価 :
252 = :
// 1970年01月01日 00:00:00 UTC (Unix エポック)
var dt3 = new Date( 1970, 0, 1, 0, 0, 0 );
console.log ( dt3 );
console.log ( dt3.toLocaleString( 'en-US', { timeZone: 'Asia/Tokyo', hour12: false } ) );
出力
1969-12-31T15:00:00.000Z
1/1/1970, 00:00:00
ひとまず、内部ではUTC にして、
表示する際に、互換性は低いけど、toLocaleString で表示できた。
ただ、1970-01-01 のように表示できない
Windows10 のPC だけど、設定ファイルで出来ないのかな?
Linux では環境変数で設定しているけど
date-fns, date-utils も、調べてみる
254 = :
単に、Windows10 のPC に、VSCode, Node.js を入れて、サンプルを実行しているだけ。
プロジェクトも作っていない。
未設定ワークスペースで、.js ファイルを実行しているだけ
VSCode の拡張機能、Quokka.js で実行すると正常だけど、
VSCode の拡張機能、Code Runner で右クリックメニューから実行するか、
端末から、node コマンドで実行すると、9時間ズレるのが不思議
255 = :
9時間ズレるのが不思議なの?w
日本標準時(JST)が世界標準時(UTC)マイナス9時間だからだよwww
257 = :
>>255
そんなの誰でも知ってる
威張るな
258 = :
nodeの場合デプロイ先のリージョンがアメリカかヨーロッパかでズレたらそっちのほうが困るがな。
259 = :
ただ、VSCode の拡張機能、Quokka.js で実行すると、日本時間になる
console.log ( dt3.toLocaleString( 'en-US', { timeZone: 'Asia/Tokyo', hour12: false } ) );
とにかく、console.log の度に、こう書くのが面倒くさい。
設定ファイルか何かで、どうにか出来ないかな?
260 = :
This is arguably a V8 bug. It ignores locale settings. In fact, all date and number formatting logic is hard-coded.
The reason it works in Chrome and Chromium is that those projects use v8-i18n on top of V8. I don't think that's a direction we want to take. It depends on libicu and that's a massive library.
We would have to bundle it and that would increase our already large source tree by another 85 MB and ~500,000 LoC.
http://github.com/nodejs/node-v0.x-archive/issues/4689
262 = :
>>260
以下は、自動翻訳
これは間違いなくV8のバグです。 ロケール設定は無視されます。
実際、日付と数値のフォーマットロジックは、すべてハードコーディングされています
ChromeとChromiumで動作するのは、これらのプロジェクトがV8の上にv8-i18nを使用しているからです。
それが私たちが望む方向ではないと思います。 それはlibicuに依存しており、それは大規模なライブラリです。
これをバンドルする必要があります。
これにより、すでに大きなソースツリーがさらに85 MB、最大500,000 LoC増加することになります
263 = :
えぇバグなの
しかもデカイな
264 = :
バグではない
そもそもIOからも分離されたJSという言語のエンジンで
文字列をパースして評価する+標準出力に出すくらいのことしかしなくていいのに
ここだけ環境もといOSからロケーションを取得して(1個とは限らなかったりするし)適切に扱うとか異質
なので仕様にも実装していない場合や実装内で利用できない場合はオフセットを0として良いとしており
つまり実質的にこの仕様の実装はオプションだ サポートしていなくてもJSエンジンとして正しい
だからV8コアと国際対応は分離されているのにそれをNodeが取り入れたがらないだけ
265 = :
パッチ公開してる人いるから自分でnodeビルドすればいけるぞ
266 = :
デベロッパーツールでオリジン関係なくjsを実行できてしまうけど、そうするとサイトにいくらでも攻撃できちゃうのはどう対処すればいいの?
認証トークンもバレバレ、api実行もできるんだけど
267 = :
サーバーの設定でわざわざ全てのオリジンにcors許可してるんだろマヌケw
268 = :
マヌケって俺のサイトじゃないんだが?
270 = :
認証関係は、twitter など、大手の認証を使う
各社で、パスワードなどを管理したら、漏えいするから危険!
271 = :
認証トークンは、1 time password とかだろ
1回限りのものだから、わかっても次には使えない
272 = :
>>270
分からないのに書き込むな。な?
住所晒せば大量のチラシ送ってやるぞ?
273 = :
>>262
>日付と数値のフォーマットロジックは、すべてハードコーディングされています
node では、node専用の日付時刻ライブラリを使った方が、良さそう
ブラウザでは、それと異なるコーディングをするしかないか?
そもそも、ブラウザとnodeで、共に動作する、ソースコードの需要がないか
274 = :
new Date('2018/01/01 10:12:13 +0900')
みたいに明示したらいいだけじゃないの?
275 = :
>>274
その手のフォーマットの互換性が、ハッキリしない。
使えるかどうか、よくわからない
素のJS ではなく、フォーマットのライブラリを使った方がよいかも
276 = :
classにsetterが設定されてるかどうかを、文字列から判定する方法が知りたいです
イメージ的には
class Hoge {
constructor() {
this._value ;
}
get value () { return this._value; }
set value (x) { this._value = x * 2; }
}
のようなケースで、
const hoge = new Hoge();
hoge.hasSetter('value') // true
となるようなhasSetterに相当するものです
hoge.hasOwnProperty('value') や
Object.getOwnPropertyDescriptor(hoge, 'value')
では引っかからなかったので、何か方法があれば教えていただきたいです
277 = :
Object.getOwnPropertyDescriptorはプロトタイプチェーンを辿らない
(だからOwnが名前に入ってる)
アクセサプロパティがプロトタイプチェーンにある場合、自前でプロトタイプチェーンを辿りながら判定する必要がある
279 = :
>>278
それだとsetterにかぎらんのでは
281 = :
細かい質問なんですが、ソースリストの整形の問題でエディタとかの話になるんですが
オブジェクトの記述でプロパティの名前と値の文頭をそれぞれ字下げで揃えるってことはできないでしょうか
自分はATOMのbeautifyを使ってるんですが
プロパティ名の文頭は揃っても、値の文頭が揃わないと読みづらいなと感じてます
282 = :
Atomスレで聞こうね
284 = :
値の頭そろえるとlintがうるさいからやめた
285 = :
<select>
<option value="1">aaa
<option value="2">bbb
<option value="3">ccc
</select>
のvalueの値と表示部分の一覧をjavascriptで取得することはできますか?
できるならどうやるんですか?
286 = :
>>285
こんな感じ
http://jsfiddle.net/xe4roL0w/1/
287 = :
>>286
jqueryってやつを覚えないとだめなのか
288 = :
jQuery房がやってくるぞ
289 = :
>>287
jQueryあった方が楽+早い+書きやすい+読みやすい、から使っているだけだよ
jsで書くとこんな感じになると思うけど、あまり自信は無い
http://jsfiddle.net/qzum8xkt/1/
290 = :
ここから怒涛のjQuery信仰者のご高説が始まるぞ
291 = :
jQueryはオワコンじゃない
292 = :
何をそんなに怖がってるの?
293 = :
もはや風物詩
294 = :
>>281
atom-beautifyはjs-beautifyが動いてるけど
残念ながらその設定は無い
ESLintにもPrettierにも多分ない
IntelliJ IDEAとかならできたはず
295 = :
>>287
べつに覚えなくてもいいけど。
例えばselectタグにoreoreというidが降ってあったとすると、
[...document.querySelectorAll `select#oreore > option`]
.map(opt => [opt.value, opt.textContent])
で
[["1", "aaa/n"], ["2", "bbb/n"], ["3", "ccc/n"]]
が得られる。
jQueryは内部でSizzleというjavascript製セレクタエンジン使ってるんだが、モダンブラウザの場合そっちじゃなくてこのdocument.querySelectorAllを呼び出している。
なのでその場合jQueryはムダな数万行のコードで速度・帯域・メモリ・CPUをムダに消費するゴミ。
296 = :
> なのでその場合jQueryはムダな数万行のコードで速度・帯域・メモリ・CPUをムダに消費するゴミ。
minifyされてるのを使えば、たったの1行(もしかしたら数行)だよ
1行なんだから速度・帯域・メモリ・CPUなんか気にしなくていい
297 = :
それにminify前のsizzleのコードはわずか2282行。
http://github.com/jquery/sizzle/blob/master/dist/sizzle.js
数万行とかいう嘘どこから出てきたんだ?
調べもしないでそういうことやるから信用されないんやで
298 = :
行数で比較すんなよ
せめてバイト数で
299 = :
実際DOM操作のためだけにjQuery読み込むのってコスパわるいん?
300 = :
数万行ワロタw
類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.131 + (1000) - [97%] - 2017/1/25 8:01
- + JavaScript の質問用スレッド vol.135 + (1002) - [97%] - 2018/11/23 10:30
- + JavaScript の質問用スレッド vol.130 + (974) - [97%] - 2016/10/26 14:18
- + JavaScript の質問用スレッド vol.130 + (1001) - [97%] - 2017/11/25 20:45
- + JavaScript の質問用スレッド vol.117 + (1009) - [97%] - 2014/8/5 3:30
- + JavaScript の質問用スレッド vol.131 + (1004) - [97%] - 2018/3/7 13:30
- + JavaScript の質問用スレッド vol.132 + (1001) - [97%] - 2018/4/19 11:00
- + JavaScript の質問用スレッド vol.107 + (1001) - [97%] - 2013/9/7 10:16
- + JavaScript の質問用スレッド vol.133 + (1001) - [97%] - 2018/6/8 10:45
- + JavaScript の質問用スレッド vol.134 + (1001) - [97%] - 2018/8/3 23:15
- + JavaScript の質問用スレッド vol.136 + (1001) - [97%] - 2019/1/8 11:30
- + JavaScript の質問用スレッド vol.138 + (1004) - [97%] - 2019/4/20 23:45
- + JavaScript の質問用スレッド vol.139 + (1001) - [97%] - 2019/5/27 15:15
- + JavaScript の質問用スレッド vol.127 + (1001) - [97%] - 2016/2/4 0:15
- + JavaScript の質問用スレッド vol.127 + (160) - [97%] - 2021/7/16 9:30
- + JavaScript の質問用スレッド vol.113 + (1001) - [95%] - 2014/3/15 21:30
- + JavaScript の質問用スレッド vol.118 + (1002) - [95%] - 2014/8/29 22:30
トップメニューへ / →のくす牧場書庫について