> What rule tells us that one month before December 31
is November 30? Or, what rule tells us to normalize November 31 to
November 30 rather than December 1?
End-of-month mode is needed pretty often, in my experience. Perhaps there
should be two rules so the user could choose which fits his situation? The
current method and a new method with a slightly different name, ex: AddEOM?
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of Alex Dvoretskiy
Sent: 2017 October 31, Tue 16:20
To: golang-nuts
Subject: Re: [go-nuts] time.AddDate() odd behavior
Yes, there is no particular rule for this case. I guess it depends on the
industry, department, or even particular individual. In finance, it would be
normalized to November 30. In power engineering December 1. I'm not proposing.
Just want to know other peoples opinions on this case for better Go
understanding.
On Tuesday, October 31, 2017 at 1:32:47 PM UTC-7, Ian Lance Taylor wrote:
On Tue, Oct 31, 2017 at 10:53 AM, Alex Dvoretskiy
<advore...@gmail.com <javascript:> > wrote:
>
> package main
>
> import (
> "fmt"
> "time"
> )
>
> func main() {
> t := time.Date(2009, time.December, 31, 23, 0, 0, 0, time.UTC)
> fmt.Println(t)
> fmt.Println(t.AddDate(0, -1, 0))
> }
>
> https://play.golang.org/p/hZ7nhnkepK
>
> The result is
>
> 2009-12-31 23:00:00 +0000 UTC
> 2009-12-01 23:00:00 +0000 UTC
>
>
> I think it should be:
>
> 2009-12-31 23:00:00 +0000 UTC
> 2009-11-30 23:00:00 +0000 UTC
>
>
> Documentation states that "AddDate normalizes its result in the same way
> that Date does, so, for example, adding one month to October 31 yields
> December 1, the normalized form for November 31." This is makes sense when
> you work with time.Date() function, because hours and minutes involved, time
> zones, daylight savings etc.
>
> But it doesn't make any sense If you operate with days, months, years for
> analytical purposes. I think the normal practice ("Normalization") in this
> case would be to add exactly one month just like in other languages. Not one
> month and one day.
I think the function is behaving as documented. You subtracted one
month from December 31, 2009, which gives you November 31, 2009. We
must then normalize that in the same was as the Date function, which
gives you December 1, 2009, which is what you see. I don't think we
can change this now, as it would break backward compatibility. Even
if we were willing to change it, I don't actually understand what you
are proposing. What rule tells us that one month before December 31
is November 30? Or, what rule tells us to normalize November 31 to
November 30 rather than December 1?
Ian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
