Well, you know your own requirements / situation better than I do - hence the 'general' in rule!

I reiterate that if you store localtimes, you are probably storing headaches for the future, if your stuff ever needs to go anywhere near an international terminal.

If you absolutely have to store localtimes, remember that their meaning will change whenever your servers are relocated to another zone (India?), or whenever your server/web/mainframe/user environments are tweaked by a kindly ol sysadmin.

I'm not sure if the nightmare you mention is a) because your currently stored data is in localtime (sic), or b) because you think it is hard to convert that to UTC? In any case, you don't have to change the entire world - just the corner you are responsbile for :)

Systems I work on currently have trading and operations users in 8 timezones at about 70 financial institutions. The timing of market pricing is a critical question, often asked - usually in the context of 'How old is that price' and 'When did you take that price' - especially where the same instrument trades on multiple exchanges and they are looking at comparative time-series data. There is a minor gotcha when comparing a trading day across multiple timezones - but we track effective_date distinctly from price timestamp.

In all cases, they expect the answer in their local timezone - storing it in UTC makes it a cinch to keep it all clear for users in AEST, EST, BST, CEST/CET, HKT, SGT, PHP, ETC.

As well as web-based presentation, we use the UTC timestamps for Excel and PDF extracts, and system data / XML extracts. The extracts are used on a variety of UNIX and mainframe OSs - in all cases, the standard TZ libraries make it easy for users and developers to know precisely what the timestamp means to them, and to present it in any timezone they choose.

Interestingly, one site submits its US data from a US mainframe, using EST and EDT timestamps - what a PITA to get this data synchronised with everyone else in the world... reminds me of that old favourite financial system design pattern: 'Currency? what currency? we only ever transact in Dollars!'

So, by all means store localtimes, but only do it consciously, after having properly considered the potential issues.

Regards,

Jeff

In reply to Re^3: Finding a remote time by jaa
in thread Finding a remote time by Moron

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.