Đúng. Xin gửi lời chúc mừng muộn màng tới Tổng thống McKinley, người không may qua đời tại chức chỉ hơn một năm sau đó. Tuy nhiên, điều đó không liên quan gì đến ngày 29 tháng 2, điều đó đã không xảy ra vào năm 1900
Năm nhuận không xảy ra trong năm chia hết cho 100 nhưng không chia hết cho 400. Vậy năm 2000 là năm nhuận chứ không phải năm 1900
Ý của tôi không phải là làm bạn hoang mang, mà muốn khẳng định lại rằng không có ngày 29 tháng 2 năm 1900. Nó không tồn tại ở bất cứ đâu ngoài Microsoft Excel, nơi bạn có thể thực hiện các phép tính thời gian dựa trên ngày đó
Điều đó đặt ra câu hỏi làm thế nào Microsoft có thể bỏ qua một lỗi rõ ràng như vậy?
Chắc chắn bạn sẽ
Vấn đề không phải ở Excel. Trên thực tế, Microsoft biết rõ rằng ngày 29 tháng 2 năm 1900 không phải là ngày hợp pháp khi họ viết mã Excel lần đầu tiên. Không, vấn đề là do tổ tiên trực tiếp và khá phổ biến của Excel, một chương trình có tên là Lotus 1-2-3
Lotus 1-2-3 thực sự là “ứng dụng sát thủ” đầu tiên dành cho PC. Nó tiếp quản chương trình bảng tính ban đầu, VisiCalc, một chương trình phổ biến trong những ngày đầu chạy bằng hơi nước của máy tính cá nhân. Nhưng VisiCalc không đáng trách
Hóa ra ngày 29 tháng 2 năm 1900 đã được mã hóa thành một ngày hợp pháp trong 1-2-3. Tôi không biết làm cách nào mà sự giám sát đó có thể đưa nó vào chương trình, và tôi chắc chắn không muốn biết toán học hoạt động như thế nào. Một khi lỗi được phát hiện, nó không thể sửa được. Quá nhiều bảng tính hiện có phụ thuộc vào nó. Vì vậy, trong truyền thống tốt đẹp của lập trình máy tính cũ, lỗi vẫn còn
Khi Excel được giới thiệu, bản thân nó là sản phẩm con của bảng tính gốc của Microsoft, Multiplan, họ đã kết hợp lỗi ngày 29 tháng 2 năm 1900. Xét cho cùng, Microsoft muốn duy trì khả năng tương thích 1-2-3 và không muốn mạo hiểm làm hỏng các phép tính ngày/giờ trong các bảng tính hiện có, đặc biệt là đối với các khoản vay lỗi. Do đó, vấn đề vẫn tồn tại, thậm chí cho đến ngày nay
Và nó có thể sẽ tồn tại mãi mãi, vì “duy trì khả năng tương thích” là một trong những nền tảng của hệ tư tưởng phần mềm máy tính. Vì vậy, dù có thật hay không, ngày 29 tháng 2 năm 1900 đã không bao giờ xảy ra nhưng nó có thể sẽ ở bên chúng ta mãi mãi - hoặc cho đến Ngày tận thế của người máy. Nhưng ngay cả khi đó, các robot có thể sẽ được lập trình bằng Excel, vì vậy rất có thể ngày đó sẽ không bao giờ biến mất
Như bạn đã biết, PowerFx thu hút sự tương đồng từ Microsoft Excel. Trên thực tế, trước đây Microsoft đã nói với chúng tôi rằng họ muốn có sự ngang bằng hoàn toàn giữa Power Apps và chức năng của Excel. Nhưng có một điểm chính mà Excel và Power Apps khác nhau, đó là cách diễn giải của năm 1900. Tôi không muốn coi đây là một bài học lịch sử, nhưng thật thú vị khi hiểu rằng Excel coi năm 1900 là một năm nhuận. Đó là một vấn đề mà họ không bao giờ có thể khắc phục được do sự thống trị thị trường của Excel và số lượng tệp tồn tại với ngày này được tính toán với điều này
Hãy kiểm tra xem điều này tác động như thế nào đến Power Platform, đặc biệt là Power Apps
Vấn đề
Có thể bạn không biết, Excel lưu trữ ngày ở định dạng số. Con số đại diện cho số ngày trôi qua kể từ ngày 1 tháng 1 năm 1900. Tôi đi sâu vào nhiều chi tiết hơn trong bài viết của mình “Power Automate. Chuyển đổi ngày thành số Excel”, nhưng tôi muốn bạn hiểu rằng nếu Microsoft khắc phục sự cố
- Tất cả các ngày sẽ quay trở lại một ngày, và chỉ có điều này là một vấn đề lớn. Hãy nghĩ xem có bao nhiêu ngày được lưu trữ trên toàn thế giới trong mỗi tệp Excel
- Mọi chức năng ngày liên quan sẽ cung cấp cho bạn kết quả không chính xác
Vì vậy, Microsoft đã có một quyết định lớn để thực hiện. Giữ kết quả không chính xác và duy trì nhóm giữa Excel và Power Apps hoặc “khắc phục” sự cố. Bằng cách giữ sự cố, họ sẽ gặp nhiều sự cố với các nguồn dữ liệu khác mà người dùng Power Apps như Dataverse hoặc SQL Server, có thể kể tên một số. Vì vậy, theo ý kiến của tôi, họ đã làm đúng và khắc phục sự cố
Vì vậy, đó là tác động đối với chúng tôi?
Bằng chứng là trong pudding
Vì vậy, hãy bắt đầu bằng cách làm hai việc. Trước tiên, hãy kiểm tra cách dữ liệu trong Excel được tạo và sau đó là trong Power Apps. Để có thể so sánh, hãy sử dụng hàm ISOWeekNum. Hàm này sẽ cung cấp cho chúng ta số tuần của một ngày. Chúng tôi đang sử dụng chức năng này vì hai lý do. Đầu tiên, để hiểu những gì cùng một chức năng trả về cho cùng một ngày và xem hành vi của những ngày gần với sự bắt đầu của vấn đề [29 tháng 2 năm 1900]
Đây là hàm trong Excel
Nếu nó thất bại vào ngày 30 tháng 2 [điều đó được mong đợi] và cung cấp tuần 9 cho ngày 29 tháng 2, thì đó là một ngày hợp lệ, chứng tỏ rằng đó là một năm nhuận. Bây giờ, hãy xem Power Apps và xem những gì chúng tôi nhận được
Hãy giải nén một chút những gì chúng ta đang làm. Để đảm bảo ngày chúng tôi nhận được, chúng tôi đang sử dụng “hàm Ngày” có đầu vào là một giá trị số cho năm, tháng và ngày. Tiếp theo, chúng tôi đã xác định TextInput để đặt một giá trị và xem những gì chúng tôi nhận được [bạn sẽ thấy lý do tại sao sau một phút]. Sau đó, chúng ta gọi hàm ISOWEEKNUM và lấy số của tuần. Bây giờ, hãy kiểm tra xem ngày 29 tháng 2 năm 1900 có thể tồn tại hay không tùy thuộc vào việc đó có phải là năm nhuận hay không
Bây giờ chúng ta thấy nơi mọi thứ khác nhau. Khi chúng tôi tạo ngày có giá trị không hợp lệ, Power App sẽ trả về ngày khả dụng tiếp theo [không phải lỗi]. Vì vậy, ngay cả khi hàm trả về cùng một giá trị, chúng tôi thấy rằng ngày bắt đầu khác và đó không phải là năm nhuận
suy nghĩ cuối cùng
Câu hỏi cho đến bây giờ là tại sao tôi lại đi sâu vào chi tiết như vậy khi nói đến một ngày?
Ngày tháng rất quan trọng và những chi tiết này có thể khiến bạn đau đầu nếu không biết cách xử lý.
Ngày còn rất xa nên hầu hết các bạn thậm chí sẽ không gặp phải sự cố này, nhưng việc biết những "khắc phục" này là điều cần thiết nếu bạn không muốn mất nhiều thời gian để gỡ lỗi điều gì đó lẽ ra phải đúng, nhưng thực tế lại không phải vậy
Có một đề nghị của riêng bạn hoặc không đồng ý với một cái gì đó tôi đã nói?