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.
