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