From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 758981F453 for ; Thu, 31 Jan 2019 11:00:01 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 0661B121F5F; Thu, 31 Jan 2019 19:59:59 +0900 (JST) Received: from o1678948x4.outbound-mail.sendgrid.net (o1678948x4.outbound-mail.sendgrid.net [167.89.48.4]) by neon.ruby-lang.org (Postfix) with ESMTPS id 2284C12109F for ; Thu, 31 Jan 2019 19:59:56 +0900 (JST) Received: by filter0057p3las1.sendgrid.net with SMTP id filter0057p3las1-2715-5C52D52B-34 2019-01-31 10:59:55.887754984 +0000 UTC m=+55950.136687335 Received: from herokuapp.com (ec2-54-85-221-199.compute-1.amazonaws.com [54.85.221.199]) by ismtpd0050p1iad1.sendgrid.net (SG) with ESMTP id JAuY_pxKS-CStebJKdEwmA for ; Thu, 31 Jan 2019 10:59:55.789 +0000 (UTC) Date: Thu, 31 Jan 2019 10:59:56 +0000 (UTC) From: usa@garbagecollect.jp To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 66813 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15340 X-Redmine-Issue-Author: dmikurube X-Redmine-Sender: usa X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS4HYP9wbp2K2ITwXHZD/TBg3RENf5l+Qwqwod FSrcEUpo0SGnGbbKYSi9YI9jtAxWBLwcxBputyxBrtAE11EFCaegixGI0aEXLLESnYOA8Mfe6IyXf4 qbLuDlpU+x9khA4KYVQJ8TCD7btWrzsq5+CSEmy86TrdXLgZDzkACLhNPQ== X-ML-Name: ruby-core X-Mail-Count: 91359 Subject: [ruby-core:91359] [Ruby trunk Bug#15340] Time.local behaving inconsistently for excess days after 2038 X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #15340 has been updated by usa (Usaku NAKAMURA). Backport changed from 2.3: WONTFIX, 2.4: REQUIRED, 2.5: DONE to 2.3: WONTFIX, 2.4: DONE, 2.5: DONE ruby_2_4 r66967 merged revision(s) 65974. ---------------------------------------- Bug #15340: Time.local behaving inconsistently for excess days after 2038 https://bugs.ruby-lang.org/issues/15340#change-76612 * Author: dmikurube (Dai MIKURUBE) * Status: Closed * Priority: Normal * Assignee: * Target version: * ruby -v: 2.4.1, 2.5.1 * Backport: 2.3: WONTFIX, 2.4: DONE, 2.5: DONE ---------------------------------------- Time.local accepts a day of month that exceeds the largest day of the month, for example, 2018-02-31. The behavior looks inconsistent before v.s. after 2038. Are they expected behavior? The behavior looks somewhat reasonable before 2037. The number of exceeding days is passed on the next month. 2018-02-31 exceeds for 3 days since 2018-02-28. 2018-02-31 is recognized as 2018-03-03. But after 2038, the behavior looks strange and inconsistent compared to before 2038, as shown in the example below observed in Ruby 2.4.1 and 2.5.1. The difference looks affecting Time.strptime as well. ~~~ ruby irb(main):001:0> ENV['TZ']=nil => nil irb(main):002:0> Time.local(2037,2,28,0,0,0,0) => 2037-02-28 00:00:00 +0900 irb(main):003:0> Time.local(2037,2,29,0,0,0,0) => 2037-03-01 00:00:00 +0900 irb(main):004:0> Time.local(2037,2,30,0,0,0,0) => 2037-03-02 00:00:00 +0900 irb(main):005:0> Time.local(2037,2,31,0,0,0,0) => 2037-03-03 00:00:00 +0900 irb(main):006:0> Time.local(2038,2,28,0,0,0,0) => 2038-02-28 00:00:00 +0900 irb(main):007:0> Time.local(2038,2,29,0,0,0,0) => 2038-03-01 00:00:00 +0900 irb(main):008:0> Time.local(2038,2,30,0,0,0,0) => 2038-02-28 00:00:00 +0900 irb(main):009:0> Time.local(2038,2,31,0,0,0,0) => 2038-03-01 00:00:00 +0900 irb(main):010:0> ENV['TZ']='UTC' => "UTC" irb(main):011:0> Time.local(2037,2,28,0,0,0,0) => 2037-02-28 00:00:00 +0000 irb(main):012:0> Time.local(2037,2,29,0,0,0,0) => 2037-03-01 00:00:00 +0000 irb(main):013:0> Time.local(2037,2,30,0,0,0,0) => 2037-03-02 00:00:00 +0000 irb(main):014:0> Time.local(2037,2,31,0,0,0,0) => 2037-03-03 00:00:00 +0000 irb(main):015:0> Time.local(2038,2,28,0,0,0,0) => 2038-02-28 00:00:00 +0000 irb(main):016:0> Time.local(2038,2,29,0,0,0,0) => 2038-03-01 00:00:00 +0000 irb(main):017:0> Time.local(2038,2,30,0,0,0,0) => 2038-02-28 00:00:00 +0000 irb(main):018:0> Time.local(2038,2,31,0,0,0,0) => 2038-03-01 00:00:00 +0000 ~~~ JFYI: I thought I observed a case 2038-02-30 is recognized as 2038-03-01 when ENV['TZ']=nil, but just now I couldn't reproduce the case. It might be my mistake in operations, but let me leave the log just in case. (It might be because I was in different timezones when I observed them. The example above was in JST, and the below was in PST.) ~~~ ruby irb(main):001:0> ENV['TZ']=nil => nil irb(main):002:0> Time.local(2037,2,30,0,0,0,0) => 2037-03-02 00:00:00 -0800 irb(main):003:0> Time.local(2038,2,30,0,0,0,0) => 2038-03-01 00:00:00 -0800 ~~~ -- https://bugs.ruby-lang.org/