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