I use a type TimeOfDay which is decoupled from the actual date mechanics. It's simply a wrapper around nanoseconds since midnight. Timezones and other date considerations are only applicable if you're crossing a date boundary or when converting to/from the type. It's not a registered package, but feel free to check out: https://github.com/tbreloff/CTechCommon.jl/blob/master/src/time.jl
On Fri, Apr 29, 2016 at 9:26 AM, Yichao Yu <yyc1...@gmail.com> wrote: > On Fri, Apr 29, 2016 at 9:17 AM, J Luis <jmfl...@gmail.com> wrote: > > OK, now I'm puzzled (0.4 on Win 64) > > > > julia> 2^60 > > 1152921504606846976 > > > > julia> 2^62 > > 4611686018427387904 > > > > julia> 2^63 > > -9223372036854775808 > > > > julia> 2^64 > > 0 > > > > > > This is integer overflow. > > > > > > > sexta-feira, 29 de Abril de 2016 às 14:03:52 UTC+1, Stefan Karpinski > > escreveu: > >> > >> I'll answer with a pair of questions: > >> > >> what range of dates can you represent using a 64-bit integer to > nanosecond > >> precision? > >> what range of dates can you represent using a 64-bit integer to > >> millisecond precision? > >> > >> > >> On Fri, Apr 29, 2016 at 8:06 AM, Ben Southwood <bensou...@gmail.com> > >> wrote: > >>> > >>> Are there any packages that can handle "Unix style" times? How come > >>> Julia can only handle seconds in 0.4.5 and milliseconds in 0.5 > (unstable)? > >>> Shouldn't we just aim big and go all the way to nanos? > >>> > >>> For example, it would be great if I could handle the following times. > >>> > >>> 2015-12-11 09:46:40.882362Z > >>> > >>> 2015-09-11 14:37:12.960014+01:00, > >>> > >> > > >
