2 ms·

> 99.9% of which suck goats though. The past decade has seen immense improvements, though. JodaTime is pretty neat and JSR-310 seems to be an improvement on th

> 99.9% of which suck goats though. The past decade has seen immense improvements, though. JodaTime is pretty neat and JSR-310 seems to be an improvement on that (haven't used it though). > And then, there's the problem of correctly syncing time display with internal representation [..] leap second is provided with 6 months of advance, DST/GST changes may be provided with far less (to say nothing of timezone changes). Since the time zone issue is the larger one anyway, this provides a solid (copyright trolling aside) framework for distributing this information: a database distributed and maintained as part of the OS. > Well this is a human time mapping [..] contextual mappings I agree, but it's the context that's hard. You need some way for your abstraction to capture the fact that a "minute" can sometime consist of 61 seconds. Consider an application that monitors the number of foos per minute where the developer perfectly reasonable uses the "minute" abstraction. This might then exhibit faulty behaviour when there's a leap second inserted - suddenly there's 1/60th more foos reported in a minute. Depending on the application, that might be statistically insignificant and can safely be ignored, or it might be a red flag that triggers someones pager to go off (or worse).

masklinn 15y ago
> The past decade has seen immense improvements, though. JodaTime is pretty neat and JSR-310 seems to be an improvement on that (haven't used it though). Joda is pretty much the 0.1% in question. On its own. > I agree, but it's the context that's hard. You need some way for your abstraction to capture the fact that a "minute" can sometime consist of 61 seconds. Absolutely. > Consider an application that monitors the number of foos per minute where the developer perfectly reasonable uses the "minute" abstraction. This might then exhibit faulty behaviour when there's a leap second inserted - suddenly there's 1/60th more foos reported in a minute. Ideally, this application should monitor the number of foos per [[time unit]], and only convert from [[time unit]] to minutes when it displays information. Of course you'd still have contextual issues: > Depending on the application, that might be statistically insignificant and can safely be ignored, or it might be a red flag that triggers someones pager to go off (or worse). Yeah. Unless those triggers use the rate per [[time unit]] instead of using the rate per "human" unit (would blow up on summer time end as well, as it "replays" a full human hour)

masklinn 15y ago

> The past decade has seen immense improvements, though. JodaTime is pretty neat and JSR-310 seems to be an improvement on that (haven't used it though). Joda is pretty much the 0.1% in question. On its own. > I agree, but it's the context that's hard. You need some way for your abstraction to capture the fact that a "minute" can sometime consist of 61 seconds. Absolutely. > Consider an application that monitors the number of foos per minute where the developer perfectly reasonable uses the "minute" abstraction. This might then exhibit faulty behaviour when there's a leap second inserted - suddenly there's 1/60th more foos reported in a minute. Ideally, this application should monitor the number of foos per [[time unit]], and only convert from [[time unit]] to minutes when it displays information. Of course you'd still have contextual issues: > Depending on the application, that might be statistically insignificant and can safely be ignored, or it might be a red flag that triggers someones pager to go off (or worse). Yeah. Unless those triggers use the rate per [[time unit]] instead of using the rate per "human" unit (would blow up on summer time end as well, as it "replays" a full human hour)