Ah, yes... That makes sense. But no, I do not need to represent dates billion years in the past. I was just testing if things would work by using the limits. I would only need to have dates down to around a few centuries BC.
Em ter, 6 de set de 2016 às 14:30, Jakob Borg <ja...@nym.se> escreveu: > Year() returns an int, and the playground is 32 bit, so can't represent > something smaller than about minus two billion. However if your use case is > to represent times billions of years in the past I don't think a time.Time > is the right type. There's the whole business about time zones, leap years > and so on that time.Time tries to deal with which runs into the fact that a > calendrical system didn't exist at that time. Astronomy tends to talk about > Julian years from a given point in time. Perhaps something based on that, > given that you probably don't need to refer to a time and date in a year > billions of years ago? > > //jb > On Tue, 6 Sep 2016 at 18:41, Bruno Albuquerque <b...@bug-br.org.br> wrote: > >> I was trying to store BC dates in a database and due to various issues >> with date handling and assumptions about date ranges, I decided to store >> the date as a int64 number and use time.Unix() to convert it to a time >> object. This mostly works but I found some weird behavior: >> >> https://play.golang.org/p/4zm4pw8bwP >> >> Any ideas why this is happening? >> >> -- >> 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.
