Hi! I am writing some data processing that requires tenths of seconds in the timestamps.
The %f format for microseconds does not seem to work with strftime and strptime. This little program:
// ===================================================================
// ==> wheref: %f does not work
// ===================================================================
use DateTime;
var now = datetime.now();
writeln(now.strftime("%H:%M:%S.%f"));
writef("%06i\n",now.microsecond);
exit(0);
prints
18:47:11.%f
013328
So it is interpreting %f literally … when it should be printing 18:47:11.013328
If there is a workaround, or if the format specifier is different, I would be glad to know.
This looks like a job for @diten. With a quick glance: We implement strftime() using C’s strftime() which (on my system at least) doesn’t support a microsecond %f format string, so I’m guessing we inherited that in our implementation (?). At the same time it seems likely that Python’s implementation is built in terms of C functions, so maybe we just need to work harder to replicate that feature?
A potential workaround would be to use Chapel’s time module which supports a (poorly named and due to be renamed) Timer type that works like a stopwatch. We tend to use this when needing to do benchmark timings by starting and stopping the timer around the sections we want to measure and then reading the elapsed time. But it’s less about telling you the actual time of day, so may not get you what you want if you do need the full hours:minutes:seconds.microseconds.
Hi again, Brad: The real application is reading huge text datafiles with atmospheric turbulence data acquired every 0.1 s. The time stamps are hours:minutes:seconds.microseconds and it is useful to convert them to datetime structures among other things because sometimes the datalogger misses some readings etc. I did quite a few of those things in Python, but got tired of the really slow performance or the extra effort to use just-in-time compilation (Numba) etc. so I was hoping that Chapel could do the same, only 100 x faster
Got it, thanks for the additional context, which makes it clear that the timer/stopwatch won’t serve as a stand-in. As a workaround, it seems like you’re already 99% of the way there. E.g., how about:
That said, I think this is something we need to address given that we’re storing .microsecond and trying to match Python’s capabilities here. If you’d be open to filing a GitHub issue for this, that would be great. Otherwise, we should do it.
I agree that the reason it’s missing is that the underlying C implementations we have available are missing it. I also agree that it would be reasonable for us to add it to our implementation.
I am really not savvy to do those things in github — although I know how to upload stuff there, and even have my personal home page there (nldias.github.io), so if you could handle it, I think it would be preferable. But I am more than happy to share code about this, anytime:
I can prepare a simple example with a datafile and the code that should work, and the workaround code, for example, and share with you guys. In the meantime, yes, I will get the microseconds separately, so this won’t stop me.
so if you could handle it, I think it would be preferable.
OK, I’ve filed an issue here:
If you’ve got a GitHub account, it’s easy to file issues, just point a browser here:
and describe your issue as clearly as possible (e.g., your OP here would have made a fine issue; though it’s also fine to ask questions here before filing an issue if you’re not certain it’s a bug, say).
Fixed today (see issue above). Now have to figure out a way of supporting %f in strptime(), which is harder than strftime(), since normal C strptime() does not have any way of parsing 6-digit numbers.
