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 <[email protected] > <javascript:>> 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 >>> >>> >>>
