Of course it's unlikely that any zone will actually implement an offset with sub-millisecond precision, but I'm not buying arbitrarily limiting it to milliseconds on the *input* to the compiler on that basis.
Since a 1-millisecond timezone offset corresponds to approximately 30cm longitudinal distance on the surface of the earth, I can't imagine any real (*timezone*) uses for better precision of the offsets. M. -----Original Message----- From: tz [mailto:tz-bounces@iana.org] On Behalf Of Paul G Sent: 06 February 2018 00:31 To: Howard Hinnant Cc: Time zone mailing list Subject: [External] Re: [tz] Fractional seconds in zic input
I want no truncation whatsoever. I want to do exact time arithmetic.
Then why are you advocating for a 1ms precision? If you don't want any truncation, then you should be arguing for unlimited precision representations. Anything else will necessarily be a truncation.
If I have an offset of 1ns, and I add that to a time point of 1us UTC, the result is 1001ns in time zone X. To be able to accurately represent the time point in Zone X I have to be able to exactly represent 1001ns.
True. This project does not decide what the time zones will be, though. You will have this problem if and only if some zone decides on an offset with nanosecond precision, and if that happens, tzdb will either have to truncate the real data to fit this arbitrary cutoff, or a second change to the precision supported will need to happen. Of course it's unlikely that any zone will actually implement an offset with sub-millisecond precision, but I'm not buying arbitrarily limiting it to milliseconds on the *input* to the compiler on that basis.
Howard
On Feb 5, 2018, at 4:03 PM, Paul G <paul@ganssle.io> wrote:
Yes, but you are always necessarily truncating time to the precision of your representation because time has significantly greater than nanosecond precision. Your compiler can always truncate the offsets if you want to represent "point in time" as an offset from some fixed point (e.g. the unix epoch) and you want offsets *within that representation* to have the same precision as the offset you're using to represent the point in time. Given that the realistic range of offsets is on the order of +/- 1 day, I don't think we should limit their precision to the same precision as the timestamps they may be used with.
If, as seems to be increasingly the case, we're concerned with future-proofing tzdb, it would make sense to support a very high precision like nanoseconds or go with a precision specification scheme that is effectively unlimited. Compilers are free to truncate to whatever level of precision they want in their output data.
Best, Paul
On 02/05/2018 02:51 PM, Howard Hinnant wrote:
On Feb 5, 2018, at 2:13 PM, Paul G <paul@ganssle.io> wrote:
Maybe I'm missing something, but are we talking about fractional seconds in *offsets* or fractional seconds for the time of the change?
For offsets, why would we care whether it can represent +/- 292,000 years, since it's fantastically unlikely that a time zone offset would even be outside of +/- 24 hours. While both outcomes are very unlikely, I think an offset best represented in nanoseconds is much more likely than an offset +/- 292 years...
Let’s say, just for example, that we have a UTC offset of 1ns for Zone X.
Let’s further assume that I want to map arbitrary time points between UTC and X, exactly.
Well, in order to be sure that I can map UTC to X and back to UTC again, with no loss of information, then time points in both UTC and in X must have nanosecond (or finer) precision. (disclaimer: I’m using the term “finer” here in a very coarse manner. :-) The actual requirement is that the precision of the UTC and X time points must be able to exactly represent nanosecond precision, in the same way you can exactly represent minutes precision with a type holding milliseconds precision — but not vice-versa.)
If I can only represent (for example) microsecond precision in UTC and X, then when I map a time point from UTC to X (or vice-versa), the 1ns offset will be lost when I add it to a count of microseconds, and truncate the result to microseconds. Subsequently my X time point will not be an accurate representation of the specified mapping for the X time zone. For example if I subtract UTC from local time I should get the offset, but in this example I would get 0.
Howard
This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at http://www.standardchartered.com/en/incorporation-details.html Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement on https://www.sc.com/rcs/ and Regulatory Compliance Disclosures on http://www.sc.com/rcs/fm Insofar as this communication contains any market commentary, the market commentary has been prepared by sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at https://www.sc.com/en/banking-services/market-disclaimer.html Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign on the term sheet to acknowledge in respect of the same. Please visit https://www.sc.com/en/banking-services/dodd-frank-disclosures.html for important information with respect to derivative products.