3 ms·

Is there any financial system, regime, or product that depends upon leap seconds? I have never heard of any. If so, it is safe to ignore them. When storing d

by throwaway2037 2y ago

Is there any financial system, regime, or product that depends upon leap seconds? I have never heard of any. If so, it is safe to ignore them. When storing date/time stamps, I prefer to persist into two separate fields: (a) date/time using UTC time zone and (b) original time zone offset, e.g., UTC+8. When debugging, it is useful to know the original time zone offset. And when querying and processing data, it is easier to use UTC time zone.

yareally 2y ago
Only a guess, but maybe financial markets that run 23 hours a day, 6 days a week, such as futures?
- throwaway2037 2y ago
  That is exactly why I asked. Show me a source and I will believe it.
  - yareally 2y ago
    https://www.fia.org/fia/articles/fia-coordinates-industry-preparations-leap-second-event-0 https://www.fia.org/fia/articles/fia-coordinates-industry-pr... > "Leading up to the 2015 leap second event, there was concern within the financial industry that similar issues could lead to a disruption to trading operations across exchanges, clearinghouses, brokers, investors and key service providers. The Commodity Futures Trading Commission asked U.S. futures exchanges to provide details on how they planned to approach the leap second event. Some exchanges published plans to delay the opening of trading. Several exchanges in Asia have also announced details regarding how their systems will adjust their clocks before or after the leap second, and will retain normal trading hours."
sgarland 2y ago
That’s what the TIMESTAMPTZ type does in Postgres, albeit you have to read the offset and do the math. MySQL also allows you to specify an offset. Or for a fun kludge, store them as TIMESTAMP in MySQL (just not past 2038), and it silently casts it into UTC for storage, and then back to the server’s TZ – or whatever the connection specifies – for retrieval.
dumah 2y ago
Timezone, not the offset, should generally be stored. Offsets rotate throughout the year. If you store only the offset, you can’t necessarily apply a delta to the time and localize it to the origin locale.
funcDropShadow 2y ago
No, but the representation of new year 2029 00:00 in a UTC timestamp depends on how many leap seconds happen between epoch, 1970-01-01T00:00:00, and then. If you compute the timestamp for 2029-01-01T00:00:00 UTC now, and they add another leap seconds in 2025, then your timestamp represents instead 2028-31-12T23:59:59 UTC. Depending on your business this may matter or not. Differences based on time zone changes may be even larger.
amluto 2y ago
> Is there any financial system, regime, or product that depends upon leap seconds? I have never heard of any. They’re certainly unusual. > If so, it is safe to ignore them. Really? Leap seconds have happened, and they could plausibly happen again. If so, during those leap seconds, events will occur. Do you need to record the time of those events? > When storing date/time stamps, I prefer to persist into two separate fields: (a) date/time using UTC time zone and (b) original time zone offset, e.g., UTC+8. That covers most bases for past events. It is inappropriate for many future events. Hmm, maybe a good system library would have separate types for timestamps that were actually observed (or interpolated or otherwise computed after the fact, etc) and for times of events that may not have occurred at the time of computation.
HWR_14 2y ago
> Is there any financial system, regime, or product that depends upon leap seconds? According to the standard for increasing leap seconds, they interact with the opening auction of the Tokyo Stock Exchange by delaying it one second.
- throwaway2037 2y ago
  Source for TSE? Cursory source shows nothing.
gradschool 2y ago
> If so, it is safe to ignore them. if you say so, but don't whinge if someone pulls off a major heist during a leap second by counting on you to ignore it https://www.imdb.com/title/tt0137494/ https://www.imdb.com/title/tt0137494/

yareally 2y ago

Only a guess, but maybe financial markets that run 23 hours a day, 6 days a week, such as futures?

throwaway2037 2y ago
That is exactly why I asked. Show me a source and I will believe it.
- yareally 2y ago
  https://www.fia.org/fia/articles/fia-coordinates-industry-preparations-leap-second-event-0 https://www.fia.org/fia/articles/fia-coordinates-industry-pr... > "Leading up to the 2015 leap second event, there was concern within the financial industry that similar issues could lead to a disruption to trading operations across exchanges, clearinghouses, brokers, investors and key service providers. The Commodity Futures Trading Commission asked U.S. futures exchanges to provide details on how they planned to approach the leap second event. Some exchanges published plans to delay the opening of trading. Several exchanges in Asia have also announced details regarding how their systems will adjust their clocks before or after the leap second, and will retain normal trading hours."

sgarland 2y ago

That’s what the TIMESTAMPTZ type does in Postgres, albeit you have to read the offset and do the math. MySQL also allows you to specify an offset. Or for a fun kludge, store them as TIMESTAMP in MySQL (just not past 2038), and it silently casts it into UTC for storage, and then back to the server’s TZ – or whatever the connection specifies – for retrieval.

dumah 2y ago

Timezone, not the offset, should generally be stored. Offsets rotate throughout the year. If you store only the offset, you can’t necessarily apply a delta to the time and localize it to the origin locale.

funcDropShadow 2y ago

No, but the representation of new year 2029 00:00 in a UTC timestamp depends on how many leap seconds happen between epoch, 1970-01-01T00:00:00, and then. If you compute the timestamp for 2029-01-01T00:00:00 UTC now, and they add another leap seconds in 2025, then your timestamp represents instead 2028-31-12T23:59:59 UTC. Depending on your business this may matter or not. Differences based on time zone changes may be even larger.

amluto 2y ago

> Is there any financial system, regime, or product that depends upon leap seconds? I have never heard of any. They’re certainly unusual. > If so, it is safe to ignore them. Really? Leap seconds have happened, and they could plausibly happen again. If so, during those leap seconds, events will occur. Do you need to record the time of those events? > When storing date/time stamps, I prefer to persist into two separate fields: (a) date/time using UTC time zone and (b) original time zone offset, e.g., UTC+8. That covers most bases for past events. It is inappropriate for many future events. Hmm, maybe a good system library would have separate types for timestamps that were actually observed (or interpolated or otherwise computed after the fact, etc) and for times of events that may not have occurred at the time of computation.

HWR_14 2y ago

> Is there any financial system, regime, or product that depends upon leap seconds? According to the standard for increasing leap seconds, they interact with the opening auction of the Tokyo Stock Exchange by delaying it one second.

throwaway2037 2y ago
Source for TSE? Cursory source shows nothing.

gradschool 2y ago

> If so, it is safe to ignore them. if you say so, but don't whinge if someone pulls off a major heist during a leap second by counting on you to ignore it https://www.imdb.com/title/tt0137494/ https://www.imdb.com/title/tt0137494/