I agree with that. It is an odd choice, as I've never seen any other library use a reference date like that - there may be many but in 20 years, I've not seen one.
I think your argument about Parse is valid, but in most cases, you'll be passing in a variable for the date you are parsing and the format will be in a constant, so you'd be more likely to have something like time.Parse(myTimeFormat, request.birthday) or something. It's useful to remember the reference time has a pattern, but the MST, 12 hour clock and it not being in a common order (day month, then year later) makes it less obvious, it is essentially: 01/02 03:04:05PM '06 -0700, that fact is obscured when parsing in common formats. On Thu, Aug 15, 2019 at 5:28 AM <sp55aa....@gmail.com> wrote: > I think "2006-01-02 15:04" is a good idea, but have bad practice. > you cannot understand this code directly. then it is easy to write wrong > code like: time.Parse("1970-01-01 00:00", "2011-01-19 22:15") > > On Monday, April 14, 2014 at 9:19:29 PM UTC+8, Jean de Klerk wrote: >> >> In java, we do things like new SimpleDateFormat("HH:mm:ss");. In php, >> something like date_parse_from_format("j.n.Y H:iP", $date) or just >> strtotime($date). In perl, we create a datetime parser with a pattern that >> might look like pattern => '%B %d, %Y %I:%M %p %Z'. And so on and so on. >> >> However, in go we give it this ambiguous reference time, as in t, err := >> time.Parse("2006-01-02 15:04", "2011-01-19 22:15"). >> >> This seems odd to me. On first glance, I can't tell which is layout and >> which is string, but we can move around that. Then, when using it, I'm >> uncertain as to how to change formats without looking it up, I'm uncertain >> as to whether or not my reference time is supposed to be just random >> numbers or if I should specify things like 12-hour time vs 24-hour time, or >> if post-1970 is different than pre-1970, and overall I don't understand the >> reason why we choose arbitrary numbers instead of the aforementioned >> conventions of things like Y-M-d. >> >> Thanks for any clarification on this. It's very clunky and tricky to use >> at the moment, but I'm sure I'd understand it more if I more fully >> understood the rational or what this approach solves that the other does >> not. >> > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/5d3a4adf-2b4c-4a4f-896e-85206da552a5%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/5d3a4adf-2b4c-4a4f-896e-85206da552a5%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- Michael www.brightbits.co.uk Company number: 08133555 Registered in England Registered office: 22 Finwell Road, Rainham, Kent, ME8 7PY -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAMQ_qVpHRvq2ukN0964hR64tJoLUNiN4vZLjrg%3DJswb%3D%3D7QK1Q%40mail.gmail.com.