Ian is perfectly right.
Subtracting 31 days and then manually "normalising" to end-of-month would
seem to give the result being sought here. The existing normalising rule
makes perfect mathematical sense and slipping it this way or that on some
spurious pretext will just confuse matters. Such a
uts
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
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
On Tue, Oct 31, 2017 at 10:53 AM, Alex Dvoretskiy
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 re
Hello Golang-nuts,
*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 + UTC
2009
