#DateTime with non-integral increments.

1 messages · Page 1 of 1 (latest)

proud berry
#

Hi, I'm pretty novice with Julia as a language.

I am working with sometime-series data, just a quick script to convert between formats. I have a start time for the recording and I know the sample rate. I want to create a vector of Unix timestamps so that each row of my recording can feature this field as required in the format I'm writing to.

The issue I have is that with a sample rate of say 220 Hz, the delta between each timestamp is 4.54 milliseconds. I could do all this just using floating-point numbers and then floor and convert to a unix timestamp - but I was trying to use the DateTime functions if I could, as I usually think it's best not to re-invent the wheel and try to do stuff with date and time data manually, and instead let a library handle it for you. This is what I do in most other languages to try and avoid mistakes and make my business logic more explicit.

It seems that the smallest precision for times in julia is millisceond-accuracy, and I can create an object of using Date.Milliseconds(i :: Int64) - this overall precision in the output would be fine with me, but I am then concerned about gradual drift in my recording's timestamps. Flooring this to 4ms per sample then puts the effective sample rate at 250Hz, so we have a problem after half an hour of data.

I was wondering if there's any way to do time-based arithmetic using rational or real representations. From what I know Julia is based heavily on genericism - is there a way I can use functions from the DateTime library but shoving in rational numbers in lieu of integers? Or some other known solution to this problem? Or would it simply be recommended I treat the number manually - use a floating type, generate a vector of them, then add in the unix timestamp for the first sample and round if needed only once that is done.

Thanks! Keep on slaying the snake haha.

hallow coral
#

yeah Date uses integral counts

#

it's really more designed to work with calendars, not linear time.

#

I would recommend converting each of your steps to a UInt64 unix timestamp and work with those

#

or log the first measurement as a unix timestamp and save the offsets as nanoseconds, that gives you even more precision

#

Date is meant for converting between timezones and doing calendar dates like logging specific days and times, it's not as nice as other languages where they also have a nanosecond precision clock

#

if you later need to work with the timestamps you can convert them to human readabe with unix2datetime so I think using raw unix time is still idiomatic

hallow coral
#

oh also

Dates.Nanosecond(1)

works I'm not sure why you said that it only has ms

#

I think you missed the "s", it's Nanosecond not Nanoseconds which is very confusing

#

I woud still use Float64 unix microseconds though

proud berry
#

Yeah, I realised that the nanosecond precision is really what I would need. That's obviously very fine-grained and millisecond sounded fine until I looked at the numbers and realised it's probably out-of-scope if it's limited in that way. What I was wondering initially is in some other languages I could use generics to enable working with a rational rather than an integral type and just benefit form the algorithms. The C++ chrono library for example now allows applying prefixes to units and the conversions all just work, which is really nice. You can create a literal for nanoseconds and it'll come out as a period with 10^-9 but still using integers if oyu want.

proud berry
#

When I tried Milliseconds(0.1) and got a type error I gave up and moved on from that line.

#

The package is also Dates in plural unlike most others so it's reversed XD

#

I will try that anyway thanks. I did it just using Float64 stamps as you mentioned, but I'll see if I can convert it to this representation. Strong typing over the base unit at least is a start

#

Oh

#

Okay

#

Time wraps a Nanosecond and represents a specific moment in a 24-hour day.