6
$\begingroup$

I strictly store UTC time stamps inside time series files or databases, mainly to allow processing several time series together. Timezone information is kept with each time series file or item, so conversion to local time is always possible.

However, I also see local times stored in time series files and wondered if there are any good reasons to do anything different than UTC in a general universal database (for ad hoc single time series analysis local time is indeed reasonable).

$\endgroup$

1 Answer 1

5
$\begingroup$

I think storing in UTC format is good practice. Here couple ideas that may motivate someone to deviate from that:

  • Some markets are subject to day light saving time shifts and thus it introduces additional computations to convert back and forth, having to keep track of the 2 times a year the shifts occur.

  • Some only limit themselves to an individual market, hence, there is no need to store data in UTC format. Any conversion add computational inefficiencies. So, if one only trades and analyzes Japanese data, then it may make sense for such person to only concern him/herself with local Japan time zone time stamps.

  • UTC is maybe the standard but nothing speaks against to ref all time stamps to any other agreed time zone.

$\endgroup$
3
  • $\begingroup$ I agree here - I used local time (besides UTC) for exactly these reasons (day light saving time especially). $\endgroup$
    – Richi Wa
    Feb 6, 2013 at 9:05
  • $\begingroup$ Thx, I conclude a general time series database should accept time series with either UTC or local timestamps and be able to hand out time series with UTC or local timestamps. $\endgroup$ Feb 6, 2013 at 10:58
  • 2
    $\begingroup$ I agree that all times should be in UTC time. The short term convenience will come back to bite real hard later if you are successful. We track everything using UTC internally and then let the individual exchange hookups convert into the exchanges time if required. $\endgroup$ Feb 6, 2013 at 19:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.