Múi giờ ngày giờ của Nodejs

Gần đây, tôi đã thực hiện nhiệm vụ thêm tính năng múi giờ vào Lịch giao diện người dùng TOAST, thư viện lịch JavaScript do nhóm của tôi quản lý. Tôi biết rõ rằng hỗ trợ múi giờ trong JavaScript khá kém, nhưng hy vọng rằng việc trừu tượng hóa các đối tượng dữ liệu hiện có sẽ dễ dàng giải quyết nhiều vấn đề

Tuy nhiên, hy vọng của tôi đã sai và tôi thấy thật khó để xử lý múi giờ trong JavaScript khi tôi tiến bộ hơn. Thực hiện các tính năng múi giờ ngoài định dạng thời gian đơn giản và tính toán dữ liệu thời gian với các hoạt động phức tạp (e. g. lịch) là một nhiệm vụ thực sự khó khăn. Vì lý do này, tôi đã có một trải nghiệm quý giá và thú vị về việc giải quyết một vấn đề dẫn đến gây ra nhiều vấn đề hơn.

Mục đích của bài viết này là để thảo luận về các vấn đề và giải pháp liên quan đến việc triển khai các tính năng múi giờ bằng JavaScript. Khi tôi đang viết bài viết khá dài này, tôi chợt nhận ra rằng gốc rễ của vấn đề nằm ở chỗ tôi hiểu rất kém về miền múi giờ. Về vấn đề này, trước tiên tôi sẽ thảo luận chi tiết về định nghĩa và tiêu chuẩn liên quan đến múi giờ, sau đó nói về JavaScript

Múi giờ là gì?

Múi giờ là một khu vực tuân theo giờ địa phương thống nhất được quốc gia quy định hợp pháp. Nhiều quốc gia thường có múi giờ riêng và một số quốc gia lớn, chẳng hạn như Hoa Kỳ hoặc Canada, thậm chí có nhiều múi giờ. Điều thú vị là mặc dù Trung Quốc đủ lớn để có nhiều múi giờ nhưng cô ấy chỉ sử dụng một múi giờ. Điều này đôi khi dẫn đến một tình huống khó xử khi mặt trời mọc vào khoảng 10. 00 AM ở phía tây của Trung Quốc

GMT, UTC và Độ lệch

giờ GMT

Giờ địa phương của Hàn Quốc thường là

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

1. GMT là chữ viết tắt của Greenwich Mean Time, là giờ theo đồng hồ tại Đài thiên văn Hoàng gia ở Greenwich, U. K. nằm ở kinh độ 0. Hệ thống GMT bắt đầu phổ biến vào tháng 2. ngày 5 tháng 1 năm 1925 và trở thành chuẩn giờ thế giới cho đến tháng 1. 1, 1972

UTC

Nhiều người coi GMT và UTC giống nhau và cả hai được sử dụng thay thế cho nhau trong nhiều trường hợp, nhưng chúng thực sự khác nhau. UTC được thành lập vào năm 1972 để bù đắp cho vấn đề quay chậm của Trái đất. Hệ thống thời gian này dựa trên Giờ nguyên tử quốc tế, sử dụng tần số nguyên tử xesi để thiết lập tiêu chuẩn thời gian. Nói cách khác, UTC là hệ thống thay thế chính xác hơn cho GMT. Mặc dù chênh lệch múi giờ thực tế giữa hai loại này rất nhỏ, nhưng UTC vẫn là lựa chọn chính xác hơn cho các nhà phát triển phần mềm

Khi hệ thống vẫn đang được phát triển, những người nói tiếng Anh muốn đặt tên cho hệ thống là CUT (Giờ phối hợp quốc tế) và những người nói tiếng Pháp muốn đặt tên cho nó là TUC (Temps Universal Coordonn). Tuy nhiên, không bên nào thắng trong cuộc chiến, vì vậy họ đã đi đến thỏa thuận sử dụng UTC để thay thế, vì nó chứa tất cả các chữ cái cần thiết (C, T và U)

Bù lại

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

2 trong

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

3 có nghĩa là giờ địa phương sớm hơn 9 giờ so với giờ chuẩn UTC. Điều này có nghĩa là đó là 09. 00 PM ở Hàn Quốc khi đó là 12. 00 PM trong vùng UTC. Sự khác biệt về thời gian giữa giờ chuẩn UTC và giờ địa phương được gọi là "độ lệch", được thể hiện theo cách này.

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

2,

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

5, v.v.

Các quốc gia thường đặt tên cho múi giờ của mình bằng tên riêng của họ. Ví dụ: múi giờ của Hàn Quốc được gọi là KST (Giờ chuẩn Hàn Quốc) và có một giá trị bù nhất định được biểu thị bằng

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

6. Tuy nhiên, phần bù

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

2 cũng được sử dụng bởi không chỉ Hàn Quốc mà còn cả Nhật Bản, Indonesia và nhiều quốc gia khác, điều đó có nghĩa là mối quan hệ giữa phần bù và tên múi giờ không phải là 1. 1 nhưng 1. N. Danh sách các quốc gia trong phần bù

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

2 có thể được tìm thấy trong UTC+09. 00

Một số bù trừ không hoàn toàn trên cơ sở hàng giờ. Ví dụ: Bắc Triều Tiên sử dụng

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

9 làm giờ chuẩn trong khi Úc sử dụng

const d1 = new Date('2017-03-11T11:30:00');
const d2 = new Date('2017-03-11T11:30:00Z');
d1.toString(); // "Sat Mar 11 11:30:00 UTC+0900 2017"
d2.toString(); // "Sat Mar 11 20:30:00 UTC+0900 2017"

0 hoặc

const d1 = new Date('2017-03-11T11:30:00');
const d2 = new Date('2017-03-11T11:30:00Z');
d1.toString(); // "Sat Mar 11 11:30:00 UTC+0900 2017"
d2.toString(); // "Sat Mar 11 20:30:00 UTC+0900 2017"

1 tùy thuộc vào khu vực

Toàn bộ danh sách bù giờ UTC và tên của chúng có thể được tìm thấy trong Danh sách bù giờ UTC

Múi giờ. == bù?

Như tôi đã đề cập trước đó, chúng tôi sử dụng tên của các múi giờ (KST, JST) thay thế cho nhau với phần bù mà không phân biệt chúng. Nhưng không đúng khi coi thời gian và độ lệch của một vùng nhất định như nhau vì những lý do sau

Giờ mùa hè (DST)

Mặc dù thuật ngữ này có thể xa lạ với một số quốc gia nhưng rất nhiều quốc gia trên thế giới đã áp dụng giờ mùa hè. “Giờ mùa hè” là một thuật ngữ chủ yếu được sử dụng ở Hoa Kỳ. K. và các nước Châu Âu khác. Trên bình diện quốc tế, nó thường được gọi là Giờ tiết kiệm ánh sáng ban ngày (DST). Nó có nghĩa là nâng đồng hồ lên trước một giờ so với giờ tiêu chuẩn trong thời gian mùa hè

Ví dụ: California ở Hoa Kỳ sử dụng PST (Giờ chuẩn Thái Bình Dương) trong thời gian mùa đông và sử dụng PDT (Giờ ban ngày Thái Bình Dương,

const d1 = new Date('2017-03-11T11:30:00');
const d2 = new Date('2017-03-11T11:30:00Z');
d1.toString(); // "Sat Mar 11 11:30:00 UTC+0900 2017"
d2.toString(); // "Sat Mar 11 20:30:00 UTC+0900 2017"

2) trong thời gian mùa hè. Các khu vực sử dụng hai múi giờ được gọi chung là Giờ Thái Bình Dương (PT) và tên này được sử dụng bởi nhiều khu vực của Hoa Kỳ và Canada

Sau đó, câu hỏi tiếp theo là chính xác khi mùa hè bắt đầu và kết thúc. Trên thực tế, ngày bắt đầu và ngày kết thúc của DST đều khác nhau, thay đổi theo từng quốc gia. Ví dụ, ở U. S. A và Canada, DST từng là từ Chủ nhật đầu tiên của tháng 4 lúc 02. 00 giờ sáng đến Chủ nhật cuối cùng của tháng 10 lúc 12 giờ. 00 giờ sáng cho đến năm 2006, nhưng kể từ năm 2007, DST đã bắt đầu vào Chủ nhật thứ hai của tháng 3 lúc 02 giờ. 00 AM đến Chủ Nhật đầu tiên của tháng 11 lúc 02. 00 giờ sáng. Ở châu Âu, giờ mùa hè được áp dụng thống nhất trên các quốc gia, trong khi DST được áp dụng dần dần cho từng múi giờ ở các bang

Múi giờ có thay đổi không?

Như tôi đã đề cập ngắn gọn trước đó, mỗi quốc gia có quyền riêng trong việc xác định múi giờ sẽ sử dụng, điều đó có nghĩa là múi giờ của quốc gia đó có thể bị thay đổi vì bất kỳ lý do chính trị và/hoặc kinh tế nào. Ví dụ, ở các bang, thời gian của DST đã được thay đổi vào năm 2007 do Tổng thống George Bush đã ký chính sách năng lượng vào năm 2005. Ai Cập và Nga đã từng sử dụng DST, nhưng họ đã ngừng sử dụng từ năm 2011

Trong một số trường hợp, một quốc gia có thể thay đổi không chỉ DST mà cả giờ tiêu chuẩn của mình. Ví dụ: Samoa đã từng sử dụng chênh lệch

const d1 = new Date('2017-03-11T11:30:00');
const d2 = new Date('2017-03-11T11:30:00Z');
d1.toString(); // "Sat Mar 11 11:30:00 UTC+0900 2017"
d2.toString(); // "Sat Mar 11 20:30:00 UTC+0900 2017"

3, nhưng sau đó đã đổi thành chênh lệch

const d1 = new Date('2017-03-11T11:30:00');
const d2 = new Date('2017-03-11T11:30:00Z');
d1.toString(); // "Sat Mar 11 11:30:00 UTC+0900 2017"
d2.toString(); // "Sat Mar 11 20:30:00 UTC+0900 2017"

4 để giảm tổn thất trong giao dịch do chênh lệch múi giờ giữa Samoa và Úc & New Zealand. Quyết định này khiến cả nước lỡ mất cả ngày tháng 12. ngày 30 tháng 11 năm 2011 và nó đã được đăng trên các tờ báo trên toàn thế giới

Hà Lan đã từng sử dụng phần bù

const d1 = new Date('2017-03-11T11:30:00');
const d2 = new Date('2017-03-11T11:30:00Z');
d1.toString(); // "Sat Mar 11 11:30:00 UTC+0900 2017"
d2.toString(); // "Sat Mar 11 20:30:00 UTC+0900 2017"

5, chính xác không cần thiết từ năm 1909, nhưng đã đổi thành phần bù

const d1 = new Date('2017-03-11T11:30:00');
const d2 = new Date('2017-03-11T11:30:00Z');
d1.toString(); // "Sat Mar 11 11:30:00 UTC+0900 2017"
d2.toString(); // "Sat Mar 11 20:30:00 UTC+0900 2017"

6 vào năm 1937, rồi lại đổi thành phần bù

const d1 = new Date('2017-03-11T11:30:00');
const d2 = new Date('2017-03-11T11:30:00Z');
d1.toString(); // "Sat Mar 11 11:30:00 UTC+0900 2017"
d2.toString(); // "Sat Mar 11 20:30:00 UTC+0900 2017"

7 vào năm 1940, gắn bó cho đến nay

Múi giờ 1. bù N

Tóm lại, một múi giờ có thể có một hoặc nhiều độ lệch. Thời gian bù trừ mà một quốc gia sẽ sử dụng làm giờ tiêu chuẩn tại một thời điểm nhất định có thể thay đổi do lý do chính trị và/hoặc kinh tế

Đây không phải là vấn đề lớn trong cuộc sống hàng ngày, nhưng đó là khi cố gắng hệ thống hóa nó dựa trên các quy tắc. Hãy tưởng tượng rằng bạn muốn đặt thời gian tiêu chuẩn cho điện thoại thông minh của mình bằng cách sử dụng phần bù. Nếu bạn sống ở khu vực áp dụng DST, thời gian trên điện thoại thông minh của bạn sẽ được điều chỉnh bất cứ khi nào DST bắt đầu và kết thúc. Trong trường hợp này, bạn sẽ cần một khái niệm kết hợp thời gian tiêu chuẩn và DST vào một múi giờ (e. g. Giờ Thái Bình Dương)

Nhưng điều này không thể được thực hiện chỉ với một vài quy tắc đơn giản. Ví dụ: khi các tiểu bang thay đổi ngày DST bắt đầu và kết thúc vào năm 2007, ngày 31 tháng 5 năm 2006 nên sử dụng PDT (

const d1 = new Date('2017-03-11T11:30:00');
const d2 = new Date('2017-03-11T11:30:00Z');
d1.toString(); // "Sat Mar 11 11:30:00 UTC+0900 2017"
d2.toString(); // "Sat Mar 11 20:30:00 UTC+0900 2017"

8) làm thời gian tiêu chuẩn trong khi ngày 31 tháng 3 năm 2007 nên sử dụng PST (

const d1 = new Date('2017-03-11T11:30:00');
const d2 = new Date('2017-03-11T11:30:00Z');
d1.toString(); // "Sat Mar 11 11:30:00 UTC+0900 2017"
d2.toString(); // "Sat Mar 11 20:30:00 UTC+0900 2017"

9) làm thời gian tiêu chuẩn. Điều này có nghĩa là để tham chiếu đến một múi giờ cụ thể, bạn phải biết tất cả dữ liệu lịch sử của các múi giờ tiêu chuẩn hoặc thời điểm khi các quy tắc DST được thay đổi

Bạn không thể chỉ nói, “Múi giờ của New York là PST (

const d1 = new Date('2017-03-11T11:30:00');
const d2 = new Date('2017-03-11T11:30:00Z');
d1.toString(); // "Sat Mar 11 11:30:00 UTC+0900 2017"
d2.toString(); // "Sat Mar 11 20:30:00 UTC+0900 2017"

9). ” Bạn phải cụ thể hơn bằng cách nói, ví dụ: “Múi giờ hiện tại của New York là PST. ” Tuy nhiên, chúng tôi cần một biểu thức chính xác hơn để triển khai hệ thống. Quên từ “múi giờ”. Bạn cần nói, “New York hiện đang sử dụng PST làm giờ chuẩn”

Sau đó, chúng ta nên sử dụng cái gì ngoài phần bù để chỉ định múi giờ của một khu vực cụ thể? . Để cụ thể hơn, bạn nên nhóm các khu vực nơi các thay đổi về DST hoặc múi giờ tiêu chuẩn đã được áp dụng thống nhất vào một múi giờ và tham khảo nó khi thích hợp. Bạn có thể sử dụng các tên như PT (Giờ Thái Bình Dương), nhưng thuật ngữ đó chỉ kết hợp giờ tiêu chuẩn hiện tại và DST của nó, không nhất thiết là tất cả các thay đổi lịch sử. Hơn nữa, vì PT hiện chỉ được sử dụng ở Hoa Kỳ và Canada, bạn cần có nhiều tiêu chuẩn được thiết lập tốt hơn từ các tổ chức đáng tin cậy để sử dụng phần mềm phổ biến

Cơ sở dữ liệu múi giờ IANA

Nói thật với bạn, các múi giờ giống một cơ sở dữ liệu hơn là một tập hợp các quy tắc vì chúng phải chứa tất cả các thay đổi lịch sử có liên quan. Có một số cơ sở dữ liệu tiêu chuẩn được thiết kế để xử lý các vấn đề về múi giờ và cơ sở dữ liệu được sử dụng thường xuyên nhất là Cơ sở dữ liệu múi giờ IANA. Thường được gọi là cơ sở dữ liệu tz (hoặc tzdata), Cơ sở dữ liệu múi giờ IANA chứa dữ liệu lịch sử về giờ chuẩn địa phương trên toàn cầu và các thay đổi DST. Cơ sở dữ liệu này được tổ chức để chứa tất cả dữ liệu lịch sử hiện có thể kiểm chứng để đảm bảo tính chính xác về thời gian kể từ thời Unix (

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

01). Mặc dù nó cũng có dữ liệu trước năm 1970 nhưng độ chính xác không được đảm bảo

Quy ước đặt tên tuân theo quy tắc Khu vực/Vị trí. Khu vực thường đề cập đến tên của một lục địa hoặc đại dương (Châu Á, Châu Mỹ, Thái Bình Dương) trong khi Vị trí là tên của các thành phố lớn như Seoul và New York chứ không phải là tên của các quốc gia (Điều này là do tuổi thọ của một quốc gia ngắn hơn nhiều . Ví dụ: múi giờ của Hàn Quốc là

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

02 và của Nhật Bản là

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

03. Mặc dù hai quốc gia chia sẻ cùng một

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

3, cả hai quốc gia có lịch sử khác nhau về múi giờ. Đó là lý do tại sao hai quốc gia được xử lý bằng các múi giờ riêng biệt

Cơ sở dữ liệu múi giờ IANA được quản lý bởi nhiều cộng đồng nhà phát triển và nhà sử học. Các sự kiện lịch sử mới được tìm thấy và các chính sách của chính phủ được cập nhật ngay vào cơ sở dữ liệu, làm cho nó trở thành nguồn đáng tin cậy nhất. Hơn nữa, nhiều hệ điều hành dựa trên UNIX, bao gồm Linux và macOS cũng như các ngôn ngữ lập trình phổ biến, bao gồm Java và PHP, sử dụng nội bộ cơ sở dữ liệu này

Lưu ý rằng Windows không có trong danh sách hỗ trợ trên. Đó là bởi vì Windows sử dụng cơ sở dữ liệu riêng của nó được gọi là Cơ sở dữ liệu Múi giờ của Microsoft. Tuy nhiên, cơ sở dữ liệu này không phản ánh chính xác những thay đổi trong lịch sử và chỉ được quản lý bởi Microsoft. Do đó, nó kém chính xác và đáng tin cậy hơn IANA

Cơ sở dữ liệu múi giờ JavaScript và IANA

Như tôi đã đề cập ngắn gọn trước đó, tính năng múi giờ của JavaScript khá kém. Vì nó mặc định tuân theo múi giờ của khu vực (cụ thể hơn là múi giờ được chọn lúc cài đặt hệ điều hành) nên không có cách nào thay đổi nó sang múi giờ mới. Ngoài ra, thông số kỹ thuật của nó cho tiêu chuẩn cơ sở dữ liệu thậm chí còn không rõ ràng, bạn sẽ nhận thấy điều này nếu xem kỹ thông số kỹ thuật cho ES2015. Chỉ có một vài tuyên bố mơ hồ được nêu về múi giờ địa phương và tính khả dụng của DST. Chẳng hạn, DST được định nghĩa như sau. ECMAScript 2015 — Điều chỉnh thời gian tiết kiệm ánh sáng ban ngày

Thuật toán phụ thuộc vào việc triển khai sử dụng thông tin sẵn có tốt nhất về múi giờ để xác định điều chỉnh thời gian tiết kiệm ánh sáng ban ngày cục bộ DaylightSavingTA(t), được đo bằng mili giây. Việc triển khai ECMAScript dự kiến ​​sẽ nỗ lực hết sức để xác định điều chỉnh thời gian tiết kiệm ánh sáng ban ngày tại địa phương

Có vẻ như nó chỉ đơn giản nói rằng, “Này, các bạn, hãy thử và cố gắng hết sức để nó hoạt động. ” Điều này cũng gây ra vấn đề về khả năng tương thích giữa các nhà cung cấp trình duyệt. Bạn có thể nghĩ “Thật cẩu thả. ”, nhưng sau đó bạn sẽ nhận thấy một dòng khác ngay bên dưới

GHI CHÚ. Việc triển khai nên sử dụng thông tin múi giờ của Cơ sở dữ liệu múi giờ IANA http. //www. iana. org/múi giờ/

Đúng. Thông số kỹ thuật ECMA đưa ra kết quả cho bạn với đề xuất đơn giản này dành cho Cơ sở dữ liệu múi giờ IANA và JavaScript không có cơ sở dữ liệu tiêu chuẩn cụ thể nào được chuẩn bị cho bạn. Do đó, các trình duyệt khác nhau sử dụng các hoạt động múi giờ của riêng chúng để tính toán múi giờ và chúng thường không tương thích với nhau. Thông số kỹ thuật ECMA sau đó đã thêm tùy chọn sử dụng múi giờ IANA trong ECMA-402

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

05 cho API quốc tế. Tuy nhiên, tùy chọn này vẫn kém tin cậy hơn nhiều so với các ngôn ngữ lập trình khác

Múi giờ trong Môi trường Máy chủ-Máy khách

Chúng tôi sẽ giả sử một kịch bản đơn giản trong đó múi giờ phải được xem xét. Giả sử chúng ta sẽ phát triển một ứng dụng lịch đơn giản sẽ xử lý thông tin về thời gian. Khi người dùng nhập ngày và giờ vào trường trên trang đăng ký trong môi trường máy khách, dữ liệu sẽ được chuyển đến máy chủ và được lưu trữ trong DB. Sau đó máy khách nhận dữ liệu lịch trình đã đăng ký từ máy chủ để hiển thị lên màn hình

Có một cái gì đó để xem xét ở đây mặc dù. Điều gì sẽ xảy ra nếu một số khách hàng truy cập máy chủ ở các múi giờ khác nhau? . 30 AM ở Seoul phải được hiển thị là Mar 10, 2017 09. 30 giờ chiều khi lịch trình được tra cứu ở New York. Để máy chủ hỗ trợ khách hàng từ các múi giờ khác nhau, lịch trình được lưu trữ trong máy chủ phải có giá trị tuyệt đối không bị ảnh hưởng bởi múi giờ. Mỗi máy chủ có một cách khác nhau để lưu trữ các giá trị tuyệt đối và điều đó nằm ngoài phạm vi của bài viết này vì tất cả đều khác nhau tùy thuộc vào máy chủ hoặc môi trường cơ sở dữ liệu. Tuy nhiên, để tính năng này hoạt động, ngày và giờ được chuyển từ máy khách sang máy chủ phải là các giá trị dựa trên cùng một giá trị bù (thường là UTC) hoặc các giá trị cũng bao gồm dữ liệu múi giờ của môi trường máy khách

Thực tế phổ biến là loại dữ liệu này được truyền dưới dạng thời gian Unix dựa trên UTC hoặc ISO-8601 có chứa thông tin bù. Trong ví dụ trên, nếu 11. 30 giờ sáng ngày 11 tháng 3 năm 2017 tại Seoul sẽ được chuyển đổi thành thời gian Unix, nó sẽ là một loại số nguyên có giá trị là

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

06. Theo ISO-8601, nó sẽ là một loại chuỗi có giá trị là

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

07

Nếu bạn đang làm việc với điều này bằng cách sử dụng JavaScript trong môi trường trình duyệt, bạn phải chuyển đổi giá trị đã nhập như được mô tả ở trên, sau đó chuyển đổi lại giá trị đó để phù hợp với múi giờ của người dùng. Cả hai nhiệm vụ này đều phải được xem xét. Theo nghĩa của ngôn ngữ lập trình, cái trước được gọi là "phân tích cú pháp" và cái sau là "định dạng". Bây giờ, hãy tìm hiểu cách chúng được xử lý trong JavaScript

Ngay cả khi bạn đang làm việc với JavaScript trong môi trường máy chủ bằng Node. js, bạn có thể phải phân tích cú pháp dữ liệu được truy xuất từ ​​máy khách tùy theo trường hợp. Tuy nhiên, vì các máy chủ thường có múi giờ được đồng bộ hóa với cơ sở dữ liệu và nhiệm vụ định dạng thường được giao cho các máy khách, nên bạn có ít yếu tố cần xem xét hơn so với trong môi trường trình duyệt. Trong bài viết này, giải thích của tôi sẽ dựa trên môi trường trình duyệt

Đối tượng ngày tháng trong JavaScript

Trong JavaScript, các tác vụ liên quan đến ngày hoặc giờ được xử lý bằng đối tượng

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

08. Nó là một đối tượng gốc được định nghĩa trong ECMAScript, như

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

09 hoặc

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

90. phần lớn được triển khai trong mã gốc như C++. API của nó được mô tả rõ trong Tài liệu MDN. Nó bị ảnh hưởng rất nhiều bởi java của Java. sử dụng. lớp ngày. Kết quả là, nó thừa hưởng một số đặc điểm không mong muốn, chẳng hạn như các đặc điểm của dữ liệu có thể thay đổi và

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

91 bắt đầu bằng 0

Đối tượng

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

08 của JavaScript quản lý nội bộ dữ liệu thời gian bằng các giá trị tuyệt đối, chẳng hạn như thời gian Unix. Tuy nhiên, các hàm tạo và phương thức như hàm

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

93, hàm

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

94, hàm

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

95, v.v. bị ảnh hưởng bởi múi giờ địa phương của khách hàng (chính xác là múi giờ của hệ điều hành đang chạy trình duyệt). Do đó, nếu bạn tạo một đối tượng

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

08 trực tiếp bằng cách sử dụng dữ liệu đầu vào của người dùng, dữ liệu sẽ phản ánh trực tiếp múi giờ địa phương của khách hàng

Như tôi đã đề cập trước đó, JavaScript không cung cấp bất kỳ cách tùy ý nào để thay đổi múi giờ. Do đó, tôi sẽ giả sử một tình huống ở đây có thể sử dụng trực tiếp cài đặt múi giờ của trình duyệt

Tạo đối tượng ngày với đầu vào của người dùng

Hãy quay lại ví dụ đầu tiên. Giả sử rằng một người dùng đã nhập 11. 30 AM, ngày 11 tháng 3 năm 2017 trên thiết bị theo múi giờ của Seoul. Dữ liệu này được lưu trữ trong 5 số nguyên 2017, 2, 11, 11 và 30 — mỗi số đại diện cho năm, tháng, ngày, giờ và phút tương ứng. (Vì tháng bắt đầu bằng 0 nên giá trị phải là 3–1=2. ) Với hàm tạo, bạn có thể dễ dàng tạo đối tượng Ngày tháng bằng các giá trị số

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

6

Nếu bạn nhìn vào giá trị được trả về bởi

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

97, thì bạn sẽ biết rằng giá trị tuyệt đối của đối tượng được tạo là 11. 30 AM, ngày 11/03/2017 dựa trên offset

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

2 (KST)

Bạn cũng có thể sử dụng hàm tạo cùng với dữ liệu chuỗi. Nếu bạn sử dụng một giá trị chuỗi cho đối tượng

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

08, nó sẽ gọi nội bộ

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

00 và tính toán giá trị phù hợp. Chức năng này hỗ trợ thông số kỹ thuật RFC2888 và thông số kỹ thuật ISO-8601. Tuy nhiên, như được mô tả trong MDN's Date. parse() Document, giá trị trả về của phương thức này thay đổi tùy theo trình duyệt và định dạng của loại chuỗi có thể ảnh hưởng đến dự đoán giá trị chính xác. Vì vậy, không nên sử dụng phương pháp này

Ví dụ: một chuỗi như

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

01 trả về

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

02 trên Safari và Internet Explorer trong khi cùng một chuỗi trả về múi giờ địa phương trên Chrome và Firefox. Trong một số trường hợp, nó trả về giá trị dựa trên tiêu chuẩn UTC

Tạo đối tượng ngày bằng dữ liệu máy chủ

Bây giờ hãy giả sử rằng bạn sẽ nhận dữ liệu từ máy chủ. Nếu dữ liệu là giá trị thời gian Unix dạng số, bạn chỉ cần sử dụng hàm tạo để tạo đối tượng

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

08. Mặc dù tôi đã bỏ qua phần giải thích trước đó, khi hàm tạo

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

08 nhận một giá trị duy nhất làm tham số duy nhất, nó được nhận dạng là giá trị thời gian Unix tính bằng mili giây. (Thận trọng. JavaScript xử lý thời gian Unix tính bằng mili giây. Điều này có nghĩa là giá trị thứ hai phải được nhân với 1.000. ) Nếu bạn xem ví dụ bên dưới, giá trị kết quả giống với giá trị của ví dụ trước

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

Vậy nếu một loại chuỗi chẳng hạn như ISO-8601 được sử dụng thay vì thời gian Unix thì sao? . Tuy nhiên, vì ECMAScript 5 hoặc các phiên bản mới hơn chỉ định hỗ trợ ISO-8601, bạn có thể sử dụng các chuỗi ở định dạng do ISO-8601 chỉ định cho hàm tạo

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

08 trên Internet Explorer 9. 0 trở lên hỗ trợ ECMAScript 5 nếu được sử dụng cẩn thận.
Nếu bạn đang sử dụng trình duyệt không phải phiên bản mới nhất, hãy đảm bảo giữ ký tự

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

07 ở cuối. Không có nó, trình duyệt cũ của bạn đôi khi diễn giải nó dựa trên giờ địa phương của bạn thay vì UTC. Dưới đây là một ví dụ về việc chạy nó trên Internet Explorer 10.

const d1 = new Date('2017-03-11T11:30:00');
const d2 = new Date('2017-03-11T11:30:00Z');
d1.toString(); // "Sat Mar 11 11:30:00 UTC+0900 2017"
d2.toString(); // "Sat Mar 11 20:30:00 UTC+0900 2017"

Theo thông số kỹ thuật, giá trị kết quả của cả hai trường hợp phải giống nhau. Tuy nhiên, như bạn có thể thấy, các giá trị kết quả là khác nhau như

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

97 và

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

09. Trên trình duyệt mới nhất, hai giá trị này sẽ giống nhau. Để ngăn chặn loại sự cố phiên bản này, bạn phải luôn thêm

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

07 vào cuối chuỗi nếu không có dữ liệu múi giờ

Tạo dữ liệu được chuyển đến máy chủ

Bây giờ, hãy sử dụng đối tượng

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

08 đã tạo trước đó và bạn có thể tự do cộng hoặc trừ thời gian dựa trên múi giờ địa phương. Nhưng đừng quên chuyển đổi dữ liệu của bạn trở lại định dạng trước đó khi kết thúc quá trình xử lý trước khi chuyển dữ liệu trở lại máy chủ

Nếu là thời Unix, bạn chỉ cần sử dụng phương thức

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

42 để thực hiện việc này. (Lưu ý việc sử dụng mili giây. )

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

0

Thế còn các chuỗi có định dạng ISO-8601 thì sao? . 0 trở lên hỗ trợ ECMAScript 5 trở lên hỗ trợ định dạng ISO-8601. Bạn có thể tạo các chuỗi có định dạng ISO-8601 bằng phương pháp

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

43 hoặc

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

44. (

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

44 có thể được sử dụng cho các cuộc gọi đệ quy với

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

46 hoặc những người khác. ) Hai phương thức cho ra kết quả như nhau, trừ trường hợp nó xử lý dữ liệu không hợp lệ

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

9

Bạn cũng có thể sử dụng phương pháp

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

47 hoặc

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

48 để tạo chuỗi trong UTC. Khi chúng trả về một chuỗi thỏa mãn tiêu chuẩn RFC-1123, bạn có thể tận dụng điều này khi cần

Các đối tượng ngày bao gồm

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

49,

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

40 và các phương thức mở rộng của chúng. Tuy nhiên, vì chúng chủ yếu được sử dụng để trả về một chuỗi dựa trên múi giờ địa phương và chúng trả về các giá trị khác nhau tùy thuộc vào trình duyệt và hệ điều hành của bạn được sử dụng nên chúng không thực sự hữu ích

Thay đổi múi giờ địa phương

Bây giờ bạn có thể thấy rằng JavaScript cung cấp một chút hỗ trợ cho múi giờ. Nếu bạn muốn thay đổi cài đặt múi giờ địa phương trong ứng dụng của mình mà không tuân theo cài đặt múi giờ của hệ điều hành thì sao? . Giải pháp duy nhất cho vấn đề này là thêm hoặc xóa giá trị của phần bù từ ngày với điều kiện là bạn đã biết giá trị phần bù của múi giờ. Mặc dù vậy, đừng nản lòng. Hãy xem liệu có bất kỳ giải pháp nào để phá vỡ điều này

Hãy tiếp tục với ví dụ trước đó, giả sử rằng múi giờ của trình duyệt được đặt thành Seoul. Người dùng nhập 11. 30 AM, ngày 11 tháng 3 năm 2017 dựa trên giờ Seoul và muốn xem theo giờ địa phương của New York. Máy chủ truyền dữ liệu thời gian Unix tính bằng mili giây và thông báo rằng giá trị offset của New York là

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

41. Sau đó, bạn có thể chuyển đổi dữ liệu nếu bạn chỉ biết độ lệch của múi giờ địa phương

Trong trường hợp này, bạn có thể sử dụng phương pháp

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

42. Phương pháp này là API duy nhất trong JavaScript có thể được sử dụng để lấy thông tin múi giờ địa phương. Nó trả về giá trị offset của múi giờ hiện tại tính bằng phút

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

0

Giá trị trả về của

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

43 có nghĩa là múi giờ trước 540 phút so với mục tiêu. Được cảnh báo rằng dấu trừ phía trước giá trị ngược lại với dấu cộng của Seoul (

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

2). Tôi không biết tại sao, nhưng đây là cách nó được hiển thị. Nếu chúng tôi tính toán phần bù của New York bằng phương pháp này, chúng tôi sẽ nhận được

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

45. Chuyển đổi chênh lệch của

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

46 thành mili giây và tạo đối tượng Ngày mới. Sau đó, bạn có thể sử dụng các phương thức

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

47 của đối tượng đó để chuyển đổi giá trị thành định dạng bạn chọn. Hãy tạo một hàm định dạng đơn giản để so sánh kết quả

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

4

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

48 hiển thị ngày giờ chính xác theo chênh lệch múi giờ giữa Seoul và New York. Có vẻ như chúng tôi đã tìm thấy một giải pháp đơn giản. Sau đó, chúng tôi có thể chuyển đổi nó thành múi giờ địa phương nếu chúng tôi biết phần bù của khu vực không? . ” Hãy nhớ những gì tôi đã nói trước đó?

Sự cố chuyển đổi múi giờ địa phương

Nếu bạn tiếp tục làm việc với ví dụ trên thêm một chút nữa, bạn sẽ sớm gặp phải vấn đề. Người dùng muốn kiểm tra thời gian theo giờ địa phương của New York và sau đó thay đổi ngày từ ngày 10 thành ngày 15. Nếu bạn sử dụng phương thức

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

49 của đối tượng Date, bạn có thể thay đổi ngày trong khi giữ nguyên các giá trị khác

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

4

Trông có vẻ đơn giản, nhưng có một cái bẫy ẩn ở đây. Bạn sẽ làm gì nếu phải chuyển dữ liệu này trở lại máy chủ? . Do đó, bạn phải hoàn nguyên chuyển đổi trước khi gửi lại cho máy chủ

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

8

Một số bạn có thể thắc mắc tại sao tôi lại thêm bằng cách sử dụng dữ liệu đã chuyển đổi khi dù sao tôi cũng phải chuyển đổi lại dữ liệu đó trước khi quay lại. Có vẻ như tôi chỉ có thể xử lý nó mà không cần chuyển đổi và tạm thời tạo một đối tượng Ngày đã chuyển đổi chỉ khi tôi đang định dạng. Tuy nhiên, nó không phải là những gì nó có vẻ. Nếu bạn thay đổi ngày của một đối tượng

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

08 dựa trên thời gian Seoul từ ngày 11 thành ngày 15, 4 ngày sẽ được thêm vào (

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

83). Tuy nhiên, theo giờ địa phương của New York, vì ngày đã được thay đổi từ ngày 10 thành ngày 15, kết quả là 5 ngày đã được thêm vào (

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

84). Điều này có nghĩa là bạn phải tính ngày dựa trên phần bù cục bộ để có kết quả chính xác

Vấn đề không dừng lại ở đây. Có một vấn đề khác đang chờ đợi khi bạn sẽ không nhận được giá trị mong muốn bằng cách cộng hoặc trừ các phần bù. Vì ngày 12 tháng 3 là ngày bắt đầu của DST theo giờ địa phương của New York, nên phần bù của ngày 15 tháng 3 năm 2017 phải là

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

85 chứ không phải

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

41. Vì vậy, khi bạn hoàn nguyên chuyển đổi, bạn nên thêm 780 phút, ít hơn 60 phút so với trước đây

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

5

Ngược lại, nếu múi giờ địa phương của người dùng là New York và muốn biết thời gian ở Seoul, thì DST được áp dụng một cách không cần thiết, gây ra sự cố khác

Nói một cách đơn giản, bạn không thể chỉ sử dụng phần bù thu được để thực hiện các thao tác chính xác dựa trên múi giờ bạn chọn. Nếu bạn nhớ lại những gì chúng ta đã thảo luận trong phần trước của tài liệu này, bạn sẽ dễ dàng biết rằng vẫn còn lỗ hổng trong việc chuyển đổi này nếu bạn biết quy tắc giờ mùa hè. Để có được giá trị chính xác, bạn cần có cơ sở dữ liệu chứa toàn bộ lịch sử thay đổi bù trừ, chẳng hạn như Cơ sở dữ liệu múi giờ IANA

Để giải quyết vấn đề này, người ta phải lưu trữ toàn bộ cơ sở dữ liệu múi giờ và bất cứ khi nào dữ liệu ngày hoặc giờ được truy xuất từ ​​đối tượng

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

08, hãy tìm ngày và phần bù tương ứng, sau đó chuyển đổi giá trị bằng quy trình trên. Về lý thuyết, điều này là có thể. Nhưng trên thực tế, việc này tốn quá nhiều công sức và việc kiểm tra tính toàn vẹn của dữ liệu được chuyển đổi cũng sẽ khó khăn. Nhưng đừng vội thất vọng. Cho đến bây giờ, chúng tôi đã thảo luận về một số vấn đề của JavaScript và cách giải quyết chúng. Bây giờ chúng tôi đã sẵn sàng để sử dụng một thư viện được xây dựng tốt

Khoảnh khắc Múi giờ

Khoảnh khắc là một thư viện JavaScript được thiết lập tốt, gần như là tiêu chuẩn để xử lý ngày. Cung cấp nhiều API định dạng và ngày tháng, nó được rất nhiều người dùng công nhận gần đây là ổn định và đáng tin cậy. Và có Múi giờ Khoảnh khắc, một mô-đun mở rộng, giải quyết tất cả các vấn đề đã thảo luận ở trên. Mô-đun mở rộng này chứa dữ liệu của Cơ sở dữ liệu múi giờ IANA để tính toán chính xác độ lệch và cung cấp nhiều API có thể được sử dụng để thay đổi và định dạng múi giờ

Trong bài viết này, tôi sẽ không thảo luận chi tiết về cách sử dụng thư viện hoặc cấu trúc của thư viện. Tôi sẽ chỉ cho bạn thấy việc giải quyết các vấn đề mà tôi đã thảo luận trước đó đơn giản như thế nào. Ai quan tâm thì xem Moment Timezone’s Document

Hãy giải quyết vấn đề hiển thị trong hình bằng cách sử dụng Múi giờ Khoảnh khắc

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

0

Nếu bạn thấy kết quả, phần bù của

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

88 vẫn giữ nguyên trong khi phần bù của

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

89 đã được thay đổi từ

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

41 thành

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

85. Và nếu bạn sử dụng hàm

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

52, bạn có thể nhận được một chuỗi ở định dạng ISO-8601 đã áp dụng chính xác phần bù. Bạn sẽ thấy nó đơn giản như thế nào so với những gì tôi đã giải thích trước đó

Phần kết luận

Cho đến giờ, chúng ta đã thảo luận về các API múi giờ được hỗ trợ bởi JavaScript và các vấn đề của chúng. Nếu không cần thay đổi múi giờ địa phương theo cách thủ công, bạn có thể triển khai các tính năng cần thiết ngay cả với các API cơ bản miễn là bạn đang sử dụng Internet Explorer 9 trở lên. Tuy nhiên, nếu bạn cần thay đổi múi giờ địa phương theo cách thủ công, mọi thứ sẽ trở nên rất phức tạp. Ở khu vực không có giờ mùa hè và chính sách múi giờ hầu như không thay đổi, bạn có thể triển khai một phần bằng cách sử dụng

const d1 = new Date(1489199400000);
d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

53 để chuyển đổi dữ liệu. Nhưng nếu bạn muốn hỗ trợ múi giờ đầy đủ, đừng triển khai nó từ đầu. Thay vì sử dụng thư viện như Moment Timezone

Tôi đã cố gắng tự thực hiện múi giờ nhưng tôi đã thất bại, điều này không quá ngạc nhiên. Kết luận ở đây sau nhiều lần thất bại là tốt hơn hết là “dùng thư viện. ” Khi tôi mới bắt đầu viết bài báo này, tôi không biết mình sẽ viết về phần kết luận nào, nhưng chúng ta bắt đầu. Để kết luận, tôi muốn nói rằng việc sử dụng các thư viện bên ngoài một cách mù quáng mà không biết những tính năng mà chúng hỗ trợ trong JavaScript và loại vấn đề mà chúng gặp phải không phải là một cách tiếp cận được khuyến nghị. Như mọi khi, điều quan trọng là chọn đúng công cụ cho tình huống của riêng bạn. Tôi hy vọng bài viết này đã giúp bạn trong việc xác định quyết định đúng đắn của riêng bạn

Làm cách nào để đặt timeZone trong nodejs?

Làm cách nào để lấy timeZone từ ngày trong nút js?

Làm cách nào để thay đổi múi giờ trong ngày JavaScript?

Làm cách nào để chuyển đổi dấu thời gian với timeZone thành ngày trong JavaScript?