That is for others to say. I am doing it the way that I feel is best.
On Friday, July 10, 2015 at 12:15:49 PM UTC-4, Tom Breloff wrote: > > Great Jeffrey... happy to help test, although it's clear you're more of a > "time-guru" than me. Are you working on something orthogonal to > Dates/TimeZones, or is it meant to be a replacement? > > On Friday, July 10, 2015 at 12:03:52 PM UTC-4, Jeffrey Sarnoff wrote: >> >> (mine .. will :) >> I plan to have a shake-me-down, fully capable (not fully elaborated) >> version around the end of the month. >> If you would like, -- email me some test cases that are relevant to you >> (search "github jeffrey sarnoff", my email is on that page). >> I have not put any current code up on github (and the old stuff is >> antideluvian and just there for my reference). >> I would be happy to have a second set of applicative eyes in a couple of >> weeks. >> >> On Friday, July 10, 2015 at 10:11:18 AM UTC-4, Tom Breloff wrote: >>> >>> Thanks Jeffrey. Yes based on this I believe the source is erroneously >>> labeled as UTC-time since epoch, when in fact it should have been labeled >>> Unix/POSIX time. I think I have been able to get reasonable results when >>> doing something like (seconds % 86400). My uses are generally very >>> flexible in that I primarily only care about date (YYMMDD) and time of day, >>> and otherwise is just to ensure proper ordering of events. >>> >>> Regarding Jacob's method... I'm pretty sure this won't work for >>> historical dates, as this includes a constant adjustment based on today's >>> date, and doesn't account for the switch between standard and daylight >>> savings time. (it's an hour off for a timestamp during 2013-01-10). For >>> example, this is what I currently get, which uses Calendar.jl (based on >>> ICU): >>> >>> julia> Int(CTechCommon.getHoursAdjustmentFromUTC(2015,7,10)) >>> 4 >>> >>> julia> Int(CTechCommon.getHoursAdjustmentFromUTC(2013,1,10)) >>> 5 >>> >>> Looking through the Dates code, I don't see anywhere to do this kind of >>> calculation. Will TimeZones.jl be able to compute this? >>> >>> >>> On Thursday, July 9, 2015 at 5:23:07 PM UTC-4, Jeffrey Sarnoff wrote: >>>> >>>> If leapseconds do not matter, and as you are coming from using ICU, >>>> they should not. Assuming you are using market data that adheres to >>>> ICE leap second policy <https://www.theice.com/leap-second>, which >>>> explictly precludes promulgation of leap-seconds, you should be ignoring >>>> them in this specific use. >>>> If your timestamping must be done with respect to US Eastern Time, and >>>> you need to do this now -- Jacob's code makes sense. >>>> >>>> In my own experience, when timestamping market data presented obtained >>>> from (or sent to) the Eastern Time zone, applications are more flexible >>>> and >>>> less open to sequencing errors from possible future integration of >>>> additional exchange-sourced data if timestamps are formed using the "POSIX >>>> time convention <https://en.wikipedia.org/wiki/Unix_time>" (my "GMT", >>>> UTC without the leap-seconds). Of course, your app may differ in its needs. >>>> >>>> >>>> On Thursday, July 9, 2015 at 4:25:55 PM UTC-4, Tom Breloff wrote: >>>>> >>>>> The code I currently have (which does what I want, but seems overly >>>>> clunky) checks the difference between timezones "EST5EDT" and "UTC" for a >>>>> given timestamp as defined by ICU: >>>>> https://github.com/nolta/ICU.jl/blob/master/src/ICU.jl#L462. Reading >>>>> up on it further, it seems that ICU doesn't account for leap seconds, >>>>> which >>>>> I guess is what I want, since it works, however is perhaps not standard? >>>>> >>>>> Again: the end result is that I have a timestamp (UTC seconds since >>>>> epoch... not sure about leap seconds) and also the year/month/day, and I >>>>> want to know the local clock-time during the day which the timestamp was >>>>> recorded. In theory you can solve for a leap seconds conversion if >>>>> needed... I'm just easily confused as to which packages implement which >>>>> standards. >>>>> >>>>> Jacob: I'm hopeful for date/time/timezone functionality that is >>>>> straightforward and intuitive... good luck and thanks for your work! >>>>> >>>>> On Thursday, July 9, 2015 at 3:50:05 PM UTC-4, Jeffrey Sarnoff wrote: >>>>>> >>>>>> By definition, UTC incorporates leapseconds. OTOH, there is a great >>>>>> deal of software that uses UTC to mean "time at the Prime Meridan" and >>>>>> ignores leapseconds, call that GMT (it isn't, and GMT is not a current >>>>>> term >>>>>> .. but it is closer thant UTC imho). >>>>>> Which kind of time do you need as time from the Unix Epoch? >>>>>> >>>>>> 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 >>>>>>> >>>>>>> >>>>>>>
