(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 >>>>> >>>>> >>>>>
