interest in time.ParseDuration("-1week") ?

1,223 views
Skip to first unread message

Sebastien Binet

unread,
Sep 4, 2012, 8:48:22 AM9/4/12
to golan...@googlegroups.com


hi there,

migrating a python-based application to a golang-based one, I had to
handle parsing duration like the one in the title (ie: support for
'week' as a quantum of duration).

the python version was shelling-out to call
os.popen('date -d "%(duration)s" +%%Y-%%m-%%d' % dct)

yeah... nice.

but I actually had to do the same thing b/c of the lack of support for
"-1week".

looking at the code, it would seem rather straightforward to add to the
unitMap:

var unitMap = map[string]float64{
"ns": float64(Nanosecond),
"us": float64(Microsecond),
"µs": float64(Microsecond), // U+00B5 = micro symbol
"μs": float64(Microsecond), // U+03BC = Greek letter mu
"ms": float64(Millisecond),
"s": float64(Second),
"m": float64(Minute),
"h": float64(Hour),
+ "day": float64(Day),
+ "week": float64(Week),
}

where the following consts would be added:
const (
Nanosecond Duration = 1
Microsecond = 1000 * Nanosecond
Millisecond = 1000 * Microsecond
Second = 1000 * Millisecond
Minute = 60 * Second
Hour = 60 * Minute
+ Day = 24 * Hour
+ Week = 7 * Day
)

(actually, should this be 24*Hour or
23*Hour + 56*Minute + 4*Second +91*Millisecond?
ie: a sidereal day ?)

before sending a CL, I wanted to test the waters...

-s

David Symonds

unread,
Sep 4, 2012, 8:54:59 AM9/4/12
to Sebastien Binet, golan...@googlegroups.com
Duration units bigger than hour were intentionally omitted from the
time package because of the ambiguity that you mentioned and that
caused by time zone changes due to daylight saving.


Dave.

Sebastien Binet

unread,
Sep 4, 2012, 9:05:49 AM9/4/12
to David Symonds, golan...@googlegroups.com
ok, fair enough.

-s

David Wright

unread,
Sep 4, 2012, 8:58:54 AM9/4/12
to golan...@googlegroups.com, Sebastien Binet
This might be a case where a specific calendar localization would be a better place, though as far as I know there's no earthly calendar where a day isn't 24 hours, and a week isn't 7 days.

There also might be cases where leap seconds complicate things.

David

chris dollin

unread,
Sep 4, 2012, 9:36:55 AM9/4/12
to David Wright, golan...@googlegroups.com, Sebastien Binet
On 4 September 2012 13:58, David Wright <d.wrig...@gmail.com> wrote:
>... though as far as I know there's no earthly calendar where a day isn't 24 hours, ...

Twice a year, here.

Chris

--
Chris "allusive" Dollin

Ian Lance Taylor

unread,
Feb 1, 2013, 11:28:46 AM2/1/13
to bereng...@googlemail.com, golan...@googlegroups.com, David Wright, Sebastien Binet, ehog....@googlemail.com
On Fri, Feb 1, 2013 at 8:17 AM, <bereng...@googlemail.com> wrote:
>
> But if you could provide me more details of that "twice a year a day is not
> 24 hours long duration", I might get easily convinced.

When we switch to daylight savings time, the day is 23 hours long.
When we switch out of daylight savings time, the day is 25 hours long.

Ian

Berengar Lehr

unread,
Feb 1, 2013, 11:45:31 AM2/1/13
to golan...@googlegroups.com
Hm, you really got me. So yeah, you are right. And I even tried to think
about it.

You are absolutely right, if you give me a duration of 1d1h and it's
10pm on such a 23h-day, do you want After() to activate at 11pm the next
day or 10pm.

Thanks
Ber
Reply all
Reply to author
Forward
0 new messages