ΞΆ testing is welcome next Thursday -- before then, the location is in flux. I will be available to remedy any hiccups then and through that weekend.
On Tuesday, August 11, 2015 at 10:09:00 AM UTC-4, Jeffrey Sarnoff wrote: > > regarding (a) .. it does not matter to me. It matters to people who's work > discriminates sub-nanosecond occurances. > If you do, then there is a follow-up question: > Is it ok for the timestamps to be a type that wraps an ordered 2-tuple of > Int64? or a more general type -- presupposing the type > supports reduction to an integer value for ordering and interarrival > comparisons? > > regarding (b) .. I have designed a family of timestamps that allow a > suboordering over otherwise 'simultaneous' events, > There is much research on similar approachs to work with many co-extant > and cooperating processes -- this is not that > (or it is, I have not looked at that research). I do it by dedicating > some bits to sequency. I will move that into this code. > > also -- best timestamp practice incorporates a geocenter with the stamp (a > spatially situated time is stamped); > these forms are more error-resistant and easier to recover by others after > time and docs have moved on. > what is your need/preference? > > > > On Tuesday, August 11, 2015 at 9:37:35 AM UTC-4, Tom Breloff wrote: >> >> I use timestamps for various purposes, but the use case that started the >> thread: >> a) nanoseconds or microseconds >> b) possibly a few in the same micro, hundreds in the same milli... Why >> would this matter? >> c) integer is much preferred >> >> Where is the implementation? I'm curious to check out your progress. >> >> >> >> On Aug 10, 2015, at 10:45 PM, Jeffrey Sarnoff <jeffrey...@gmail.com> >> wrote: >> >> timestamp questions for Tom: >> >> (a) is the most refined temporal resolution of your timestamps >> milliseconds (1/1_000 seconds)? >> (b) do you ever get multiple items that have identical timestamps? (If >> so, what is the most you have seen.) >> (c) do you want your timestamp to be an integer (best), a float (not a >> win), or a string? (If string, all digits or not.) >> >> These timestamps will be derived from UT not from localtime (I do the >> converting), >> to do otherwise invites various problems down the road. Are all time >> values given in your local timezone? >> >> The timestamp function(s) are somewhat configurable; still, I would like >> to ensure that your use case is covered. >> >> Regards >> >> >>> >>> >>> >>> >>> On Wednesday, July 8, 2015 at 10:59:33 AM UTC-4, Tom Breloff wrote: >>>> >>>> I have some code which requires figuring out the number of seconds from >>>> the Epoch until midnight (local time) in order to quickly compute the >>>> local >>>> TimeOfDay. The reason is that I get passed a field which is seconds since >>>> Epoch, and I'd like to just subtract off the (cached) # seconds from >>>> Epoch-->Midnight. >>>> >>>> Since I'm using a cached number, I don't care so much how long it takes >>>> to calculate. Right now I use both Dates and Calendar.jl, but I'm >>>> wondering if I can accomplish this without the dependency on Calendar.jl >>>> (which I currently use ONLY to get the hours offset between Eastern US and >>>> UTC). Is there a better way to write this function? >>>> >>>> >>>> function getHoursAdjustmentFromUTC(year::Integer, month::Integer, >>>> day::Integer) >>>> millisEST = *Calendar.ymd*(year, month, day, "EST5EDT").millis >>>> millisUTC = *Calendar.ymd*(year, month, day, "UTC").millis >>>> UInt64(round((millisEST - millisUTC) / (secondsInOneHour * >>>> millisInOneSecond))) >>>> end >>>> >>>> getEpochMillis() = UInt64(DateTime(1970,1,1).instant.periods.value) >>>> createUTCDateTimeFromSecondsSinceEpoch(secondsSinceEpoch::Integer) = >>>> DateTime(Dates.UTM(secondsSinceEpoch * millisInOneSecond + >>>> getEpochMillis())) >>>> >>>> >>>> # this is the function I care about... note that "midnight" refers to >>>> midnight local to Eastern US >>>> function calcSecondsEpochToMidnight(secondsSinceEpoch::Integer) >>>> >>>> dt = createUTCDateTimeFromSecondsSinceEpoch(secondsSinceEpoch) >>>> >>>> # get the hour adjustment using the Calendar module >>>> y = Dates.year(dt) >>>> m = Dates.month(dt) >>>> d = Dates.day(dt) >>>> hourAdjustment = getHoursAdjustmentFromUTC(y, m, d) >>>> >>>> millisMidnightUTC::UInt64 = DateTime(y, m, d).instant.periods.value >>>> millisMidnightEST::UInt64 = millisMidnightUTC + hourAdjustment * >>>> secondsInOneHour * millisInOneSecond >>>> >>>> return UInt64((millisMidnightEST - getEpochMillis()) / >>>> millisInOneSecond) >>>> end >>>> >>>> >>>>
