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