Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
91 posts
|
Richard,
> I noticed I wasn't very clear about the internals of my reworked > DateAndTime, Duration, and ScaledDecimal in previous posts. > > DateAndTime instance variables: > utcMilliseconds <integer> date and time minus epoch > (1901) in microseconds. > localOffset <Duration> utcMilliseconds + offset -> > UTC (- west / 0 UTC / + east). > > Duration instance variables: > asSeconds <number> seconds long. > > ScaledDecimal instance variables: > unscaledValue <integer> unscaled digits. > scale <integer> digits to right > of decimal point. ... [show rest of quote] I've got both DateAndTime and Duration working with Fractions now. This means I've got no restrictions on the magnitude of DateAndTime and no limit on the precision of Duration whilst retaining the ability to do all calculations and comparisons exactly [1]. It's all (with the exception of Locale stuff (day names) and OS calls to get the current time and Timezone information) written in Smalltalk which, as far as I'm concerned is a plus <g> It's not finished yet, and I'll be trying to blag a copy of your test suite in the near future (please?), but it's more enjoyable than I thought it was going to be! > An associated set of SUnit Tests for the ANSI Date and Time protocols > with an implementation would be useful. I'd prefer if they used the > CampSmalltalk SUnit Testing Framework. Agreed. I did intend to write tests as I went along but, ummm, well you know <g> Ian [1] With the exception of the input/output code where I have to do a Fraction/Float conversion. |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
1765 posts
|
In reply to this post by Richard A. Harmon
Richard,
> One thing that has really been driving me nuts is what DateAndTime > class >> #clockPrecision does and how to implement it. The > description is: [SNIPPED] I think it's intended to tell you the resolution of the clock that's being used to implement <DateAndTime factory>#now. This is one of those cases where the selector itself is clearer than the "explanatory" text. I don't think it's often very useful (I suspect that the main reason for its inclusion is a holdover from systems -- common in the UNIX world -- where the system clock reports time in "ticks" rather than msecs (or whatever), and so you *need* to know how long a tick is). However it can be useful occasionally. The only case I've been able to come up with so far is: Suppose you are collecting data about the time it takes for some quick process to complete. You are going to do statistical analysis on that data. Lets say you are measuring the reaction times of a cockroach to various stimuli. Looking at the data, you notice that all the reaction times for touching its legs are the same at 10 msec, and that all the reaction times for touching its antennae are the same at 20msec. Does that mean that cockroaches have identical reaction times on all their legs ? Does it mean that it takes the horrible little beasts twice as long to react to their antennae as their legs ? You don't know unless you know the timing resolution. If the clock has a resolution of 10msec, then the above data would be almost meaningless since all you would have been doing was measuring the clock. OTOH if the clock resolution was 1msec or better, then you'd have interesting data suggesting that cockroaches are wired very oddly inside. As far as implementing it goes, the only ways of providing the guarantee that the standard mentions requires that you have access to the underlying implementation of the #now method. *If* the lower-level (OS or hardware) facility it uses provides the data (with a guarantee) that #clockPrecision requires then you can use that. I suspect that few systems do provide such guarantees, unless you have control over the hardware itself. E.g. I don't think it's possible to do it using portable C, so I don't think its possible to write a fully conforming ST implementation in portable C. Of course, I'm assuming that the option of just returning some Very Large <Duration> (10^100 years, say) is unacceptable. So, a fully portable implementation is impossible. I think you have only the options: Give up, and just return -- say -- 1 second. This conforms to the standard, but isn't actually any use to anyone. Use a loop like the one that Elliot posted to c.l.s to *measure* the resolution of the clock. This is portable but you loose the guarantee. BTW I'd go around the loop more than once for extra reliability. Since the "guarantee" required by the standard isn't actually achievable or relevant in practice (since the intent of the method is to provide info about the resolution of the clock, not to provide guarantees about the way it ticks), I'd not worry about that. This is probably the best you can do portably. Use your knowledge of the underlying implementation to "cheat". E.g. if you are doing this on Dolphin, and using the Delay class>>millisecondClockValue to help create your <DateAndTime> and <Duration> objects, then you might "know" that #millisecondClockValue has a resolution of 1 msec. This works but is non-portable. BTW. I think there's something slightly screwy about the way that ANSI put #now on <DateAndTime factory>. I'd say that there should at least be another #now on <Duration factory> (answering the <Duration> since some arbitrary, system defined, event), since: a) It is usually possible to provide this to greater precision than you can the absolute time (E.g. on UNIX you can ask the system for *either* the number of ticks since system startup, *or* the date/time accurate (if you're lucky!) to 1 second. b) Duration-since-arbitrary-event avoids all the mucking about with timezones, etc, which are built into <DateAndTime>, which can be slow, and may well be misleading. E.g. if you happened to sample the above cockroach at *just* the wrong moment in the shift between daylight saving and normal time, and you were using <DateAndTime>#now, then its reaction time (as I read the ANSI stuff) should turn out to be a Duration of 1hour 0.01secs (you can avoid that affect -- I *think* -- by converting both instances of <DateAndTime> to UTC before subtracting). The end result is that on OSs which report can report durations to greater precision than they can date/times (e.g. Windows, UNIX), it is difficult or impossible for a Smalltalk implementor to provide ANSI-compliant access to the higher resolution of the millisecond clock (or whatever). As an example, inspect: a := Array new: 2000. 1 to: a size do: [:i | a at: i put: Time now]. (a collect: [:each | each asMilliseconds]) asSet asSortedCollection asArray. You'll see that Time now (which seems to access my Windows 98 system clock) has a resolution of between 50 and 60 msecs (on this machine all the msec values are either 50 or 60 msecs apart). Using Elliot's loop (with a few refinements) for the same measurment: start := Time now. [(now := Time now) = start] whileTrue. begin := start := now. ticks := 0. [ticks < 100] whileTrue: [[(now := Time now) = start] whileTrue. start := now. ticks := ticks + 1]. end := now. (end asMilliseconds - begin asMilliseconds / ticks) asFloat. gives values which vary a little around 55.0 OTOH, using a similar loop to measure the resolution we could use for <Durations> using the Delay class: start := Delay millisecondClockValue. [(now := Delay millisecondClockValue) = start] whileTrue. begin := start := now. ticks := 0. [ticks < 100] whileTrue: [[(now := Delay millisecondClockValue) = start] whileTrue. start := now. ticks := ticks + 1]. end := now. (end - begin / ticks) asFloat. gives 1.0. (Even higher res can be obtained using KernelLibrary>>queryPerformanceCounter:) > Richard A. Harmon "The only good zombie is a dead zombie" -- chris |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
7 posts
|
In reply to this post by Richard A. Harmon
[hidden email] (Richard A. Harmon) writes:
> I noticed I wasn't very clear about the internals of my reworked > DateAndTime, Duration, and ScaledDecimal in previous posts. > > DateAndTime instance variables: > utcMilliseconds <integer> date and time minus epoch > (1901) in microseconds. > localOffset <Duration> utcMilliseconds + offset -> > UTC (- west / 0 UTC / + east). > > Duration instance variables: > asSeconds <number> seconds long. > > ScaledDecimal instance variables: > unscaledValue <integer> unscaled digits. > scale <integer> digits to right > of decimal point. > ... [show rest of quote] First, I vote for DateTime, as DateAndTime is just too ugly. Second, perhaps Duration should allow us to think in terms of Months as well. Something like: Duration instance variables: months <number> months long seconds <number> seconds long and the duration is the sum of the two, with the months instance variable always used first. So a duration of 2 years and 5 days would have months = 2 and seconds = 432,000 (5 * 86,400). When adding aDateTime + aDuration you would first add the months to aDateTime and then the seconds. I added comp.lang.smalltalk to the Newsgroups list since this issue is not limited to Dolphin. -- Jeff Hallman [hidden email] |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
91 posts
|
Jeffrey,
> First, I vote for DateTime, as DateAndTime is just too ugly. Agreed, but it's too late now to do anything about it (until the next ANSI round?) > Second, perhaps Duration should allow us to think in terms of Months as > well. That wouldn't work - how long is a month?. You would need to specify a value in days or else things like (m:d:h:m:s) 2:30:0:0:0 + 0:1:0:0:0 would be ambiguous. Should the answer be 3:1:0:0:0 or 2:31:0:0:0. If you do make a decision on 30 days per month (say) then that buggers up the addition of Duration to DateAndTime. I shan't even mention February and it's 28 (29) days. Having days as part of a Duration is fair enough, although I thought it was a bit strange at first. As Chris said earlier, it helps to reinforce the fact that Durations are not just the h:m:s in a day (as in the old Time class) but represent _any_ period of time. Ian |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
7 posts
|
I tried to send this from my home machine but it seems not to have made it.
Ian Bartholomew wrote: > > Jeffrey, > > > First, I vote for DateTime, as DateAndTime is just too ugly. > > Agreed, but it's too late now to do anything about it (until the next ANSI > round?) > > > Second, perhaps Duration should allow us to think in terms of Months as > > well. > > That wouldn't work - how long is a month?. You would need to specify a > value in days or else things like (m:d:h:m:s) 2:30:0:0:0 + 0:1:0:0:0 would > be ambiguous. Should the answer be 3:1:0:0:0 or 2:31:0:0:0. If you do make a > decision on 30 days per month (say) then that buggers up the addition of > Duration to DateAndTime. I shan't even mention February and it's 28 (29) > days. ... [show rest of quote] No, I mean that adding a month to Jan 31 gets you Feb 28 (or 29 in leap years). I don't presume there are 30 days in a month: I go by the actual calendar. This is why I specified the ordering of months first, then seconds. Days and weeks are integral multiples of seconds, but months are not, due to the varying number of days in the months. Quarters, years, decades, etc. are integral multiples of months. So you need both. End-of-month dates are special. Check out how spreadsheet dates work. If I add a month to April 29, I get May 29, but if I add a month to April 30, I get May 31, since that is the end of the month. So, what if I add one month and one day (86400 seconds) to April 29? Following the "months first, then seconds" rule gets you to May 30. If you instead add seconds first, then months, you get May 31. With this machinery and a bit of cleverness, you could create methods such as seconds, hours, days, weeks, months, etc. in Number that return Durations, and then write code like: aug31 := (DateTime yyyymmdd: 20010629) + 1 days + 2 months. oct14 := (DateTime yyyymmdd: 20010629) - 15 days + 4 months. We need 2 subtraction operators for DateTime, one considers only seconds (i.e. Julian dates) and another that considers months first, then seconds. Let's use '-' for a 'seconds only' Duration result, and '\-' for a Duration with the maximal number of months and a remander of less than 31 days. So we'd have durationOf44Days := oct14 - aug31. durationOfOneMonthAndTwoWeeks := oct14 \- aug31. I don't know if anyone has ever done date arithmetic like this in code, but it is the way we do it in everyday language, and it does lend itself to natural-looking code. -- Jeff Hallman [hidden email] |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
52 posts
|
In reply to this post by Chris Uppal-3
On Mon, 2 Jul 2001 13:55:00 +0100, "Chris Uppal"
<[hidden email]> wrote: >Richard, > >> One thing that has really been driving me nuts is what DateAndTime >> class >> #clockPrecision does and how to implement it. The >> description is: [SNIPPED] > >I think it's intended to tell you the resolution of the clock that's being >used to implement <DateAndTime factory>#now. This is one of those cases >where the selector itself is clearer than the "explanatory" text. > >I don't think it's often very useful (I suspect that the main reason for its >inclusion is a holdover from systems -- common in the UNIX world -- where >the system clock reports time in "ticks" rather than msecs (or whatever), >and so you *need* to know how long a tick is). However it can be useful >occasionally. ... [show rest of quote] [snip]
>As far as implementing it goes, the only ways of providing the guarantee >that the standard mentions requires that you have access to the underlying >implementation of the #now method. [snip] >Use a loop like the one that Elliot posted to c.l.s to *measure* the >resolution of the clock. This is portable but you loose the guarantee. BTW >I'd go around the loop more than once for extra reliability. Since the >"guarantee" required by the standard isn't actually achievable or relevant >in practice (since the intent of the method is to provide info about the >resolution of the clock, not to provide guarantees about the way it ticks), >I'd not worry about that. This is probably the best you can do portably. > [snip] Thanks for the excellent explanation. I think I better understand now what the standard is asking for. A lot of folks have managed to give me good answers to my garbled ANSI questions. I could see what Elliot's code was doing but I couldn't reconcile it with the vague notions I had that garbage collection would interfere with the guarantee. -- Richard A. Harmon "The only good zombie is a dead zombie" [hidden email] E. G. McCarthy |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
91 posts
|
In reply to this post by Jeffrey J. Hallman-2
Jeffrey,
> I don't know if anyone has ever done date arithmetic like this in code, > but it is the way we do it in everyday language, and it does lend itself > to natural-looking code. OK. I can see what you are saying but I have to disagree that the Duration class should be used in this way. An instance of the Duration class specifies a duration of time containing a given number of seconds (or fractions thereof). It has creation and accessor methods that allow the period of time that the instance represents to be viewed in more user friendly terms - days hours minutes and seconds. Because there is no set number of seconds associated with a "month" the only way you could include this behaviour is (as you suggested) to add some state to Duration, completely unconnected with the seconds aspect, that maintained the month count. To me that seems ugly, out of place and extremely prone to confusion. I can see that there might be some value in the scheme you suggest but I don't think that making the DateAndTime and Duration protocols support it is going the right way about it. I would have thought that separate Date and DateDuration classes that can recognise, and work in, periods of months, quarters or whatever might be better. I can see a lot of questions about how it would work though. Regards Ian |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
1 post
|
Hi,
If you're thinking about duration classes then also consider using a rule book that holds the date addition rules. I've used something like this before to allow date calculation that considered holidays, weekends, etc. for a banking application. e.g. In banking it's common to have to allow for holidays across multiple countries when determining a forward date for an FX trade and the holiday calendar and date rolling functions wrapped in a rule book make life a little easier. eg. aDate add: duration using: aRuleBook I suspect that there are patterns books out there that describe this better than I am able to. If anyone's interested, email me direct (after removing the SPAM blocker in the return address). Regards Ross "Ian Bartholomew" <[hidden email]> wrote in message news:8Ln07.139$zJ1.9378@wards... > Jeffrey, > > > I don't know if anyone has ever done date arithmetic like this in code, > > but it is the way we do it in everyday language, and it does lend itself > > to natural-looking code. > > OK. I can see what you are saying but I have to disagree that the Duration > class should be used in this way. An instance of the Duration class > specifies a duration of time containing a given number of seconds (or > fractions thereof). It has creation and accessor methods that allow the > period of time that the instance represents to be viewed in more user > friendly terms - days hours minutes and seconds. Because there is no set > number of seconds associated with a "month" the only way you could include > this behaviour is (as you suggested) to add some state to Duration, > completely unconnected with the seconds aspect, that maintained the month > count. To me that seems ugly, out of place and extremely prone to ... [show rest of quote] confusion.
> > I can see that there might be some value in the scheme you suggest but I > don't think that making the DateAndTime and Duration protocols support it is > going the right way about it. I would have thought that separate Date and > DateDuration classes that can recognise, and work in, periods of months, > quarters or whatever might be better. I can see a lot of questions about > how it would work though. > > Regards > Ian > > > > |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
4 posts
|
In reply to this post by Ian Bartholomew-4
Ian Bartholomew <[hidden email]> wrote in message
news:8Ln07.139$zJ1.9378@wards... > Jeffrey, > > > I don't know if anyone has ever done date arithmetic like this in code, > > but it is the way we do it in everyday language, and it does lend itself > > to natural-looking code. > > OK. I can see what you are saying but I have to disagree that the Duration > class should be used in this way. An instance of the Duration class > specifies a duration of time containing a given number of seconds (or > fractions thereof). It has creation and accessor methods that allow the > period of time that the instance represents to be viewed in more user > friendly terms - days hours minutes and seconds. Because there is no set > number of seconds associated with a "month" the only way you could include > this behaviour is (as you suggested) to add some state to Duration, > completely unconnected with the seconds aspect, that maintained the month > count. To me that seems ugly, out of place and extremely prone to ... [show rest of quote] confusion.
> > I can see that there might be some value in the scheme you suggest but I > don't think that making the DateAndTime and Duration protocols support it is > going the right way about it. I would have thought that separate Date and > DateDuration classes that can recognise, and work in, periods of months, > quarters or whatever might be better. I can see a lot of questions about > how it would work though. > Unfortunately, the simple approach which only allows durations that can be represented by fixed multiples of seconds has a very limited (in my experience) use in many domains. In several business domains where I've worked (Insurance, Credit Cards, Billing systems,...) the most important durations, by far, are months and years. Neither months nor years are fixed multiples of seconds. Does it say in the ANSI spec the only state valid in a Duration is a number of seconds? I hope not, because if months, quarters, and years can't be added and subtracted, then I'll have to stick with the Duration and TimeStamp classses we already have which do support them. I can't ever remember an occasion where I needed to add a year and so many hours to a TimeStamp (DateAndTime is definitely an ugly name). Usually I'm either using one of the longer 'indeterminate' durations (years, months, years and days, years and months, months and days, ...) or one of the shorter 'determinate' durations (days, days and hours, minutes, minutes and seconds, weeks, ...). I don't want to have to work with two sets of classes and interfaces, however. The TimeStamp and Duration classes I use work much like Jeffrey suggested: the longer indeterminate durations are evaluated before the shorter ones. If an indeterminate duration must be converted to a determinate one (asSeconds) we use an average value such as 30 days in a month. In the context of Duration arithmetic against a TimeStamp, however, the indeterminate Duration is converted exactly. Our TimeStamps are also always in Universal Coordinated Time (UTC), allowing us to convert them to a user specified timezone for display. Doug Swartz [hidden email] |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
91 posts
|
Doug,
> Does it say in the ANSI spec the only state valid in a Duration is a > number of seconds? I hope not, because if months, quarters, and > years can't be added and subtracted, then I'll have to stick with the > Duration and TimeStamp classses we already have which do support > them. The ANSI spec defines Duration factory as having two constructors - #seconds: - where the argument can be any positive or negative Number #days:hours:minutes:seconds: - where each individual argument can be a positive or negative Number There are no other constructors available and therefore no way of specifying a Duration in anything other than a specific period of time. The spec also defines an accessor, #asSeconds, which answers the number of seconds that a Duration instance represents. So to answer your question. No, the ANSI spec does not allow for arbitrary periods for the Duration classes. This also implies that a standard DateAndTime cannot either as a lot of D&T arithmetic answers a Duration as an argument/answer. > I can't ever remember an occasion where I needed to add a year and so many > hours to a TimeStamp (DateAndTime is definitely an ugly name). Usually I'm > either using one of the longer 'indeterminate' durations (years, months, > years and days, years and months, months and days, ...) or one of the > shorter 'determinate' durations (days, days and hours, minutes, minutes > and seconds, weeks, ...). I don't want to have to work with two sets of > classes and interfaces, however. The ANSI classes are just define a minimum framework so there is obviously nothing to stop you adding methods that can work in the way you want. I wouldn't think it too difficult for D&T but I don't think the Duration class will be too easy. Depends on exactly what you want I suppose. Ian |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
9 posts
|
In reply to this post by Doug Swartz
Doug Swartz wrote:
> Ian Bartholomew <[hidden email]> wrote in message > news:8Ln07.139$zJ1.9378@wards... > > Jeffrey, > > > > > I don't know if anyone has ever done date arithmetic like this in code, > > > but it is the way we do it in everyday language, and it does lend itself > > > to natural-looking code. > > > > OK. I can see what you are saying but I have to disagree that the Duration > > class should be used in this way. An instance of the Duration class > > specifies a duration of time containing a given number of seconds (or > > fractions thereof). It has creation and accessor methods that allow the > > period of time that the instance represents to be viewed in more user > > friendly terms - days hours minutes and seconds. Because there is no set > > number of seconds associated with a "month" the only way you could include > > this behaviour is (as you suggested) to add some state to Duration, > > completely unconnected with the seconds aspect, that maintained the month > > count. To me that seems ugly, out of place and extremely prone to > confusion. > > > > I can see that there might be some value in the scheme you suggest but I > > don't think that making the DateAndTime and Duration protocols support it > is > > going the right way about it. I would have thought that separate Date and > > DateDuration classes that can recognise, and work in, periods of months, > > quarters or whatever might be better. I can see a lot of questions about > > how it would work though. > > > Unfortunately, the simple approach which only allows durations that can be > represented by fixed multiples of seconds has a very limited (in my > experience) use in many domains. In several business domains where I've > worked (Insurance, Credit Cards, Billing systems,...) the most important > durations, by far, are months and years. Neither months nor years are fixed > multiples of seconds. > > Does it say in the ANSI spec the only state valid in a Duration is a number > of seconds? I hope not, because if months, quarters, and years can't be > added and subtracted, then I'll have to stick with the Duration and > TimeStamp classses we already have which do support them. > > I can't ever remember an occasion where I needed to add a year and so many > hours to a TimeStamp (DateAndTime is definitely an ugly name). ... [show rest of quote] No uglier than Timestamp. And I like DateAndTime better than DateTime. I probably like my own name better but even that one does not thrill me PointInTime. I have had need to add hours to times stamps. This is not unusual for schedule and alarm mechanisms. > Usually I'm > either using one of the longer 'indeterminate' durations (years, months, > years and days, years and months, months and days, ...) or one of the > shorter 'determinate' durations (days, days and hours, minutes, minutes and > seconds, weeks, ...). I don't want to have to work with two sets of classes > and interfaces, however. > > The TimeStamp and Duration classes I use work much like Jeffrey suggested: > the longer indeterminate durations are evaluated before the shorter ones. If > an indeterminate duration must be converted to a determinate one (asSeconds) > we use an average value such as 30 days in a month. In the context of > Duration arithmetic against a TimeStamp, however, the indeterminate Duration > is converted exactly. Our TimeStamps are also always in Universal > Coordinated Time (UTC), allowing us to convert them to a user specified > timezone for display. ... [show rest of quote] I would like to see this other classes if possible. I just wrote something similar. And I found that for my needs storing the timestamp in local time not gmt produced less conversion. Basically speaking, almost always the time stamp is displayed and compared based on its local time. Rarely on its GMT time. > > > Doug Swartz > [hidden email] |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
4 posts
|
Chris Lopeman <[hidden email]> wrote in message
news:[hidden email]... > > > Doug Swartz wrote: <snipped> > > > I can't ever remember an occasion where I needed to add a year and so many > > hours to a TimeStamp (DateAndTime is definitely an ugly name). > > No uglier than Timestamp. And I like DateAndTime better than DateTime. I > probably like my own name better but even that one does not thrill me > PointInTime. > > I have had need to add hours to times stamps. This is not unusual for schedule > and alarm mechanisms. > Yes, adding hours is common; Adding a year and some hours is uncommon. <snipped> > > > > The TimeStamp and Duration classes I use work much like Jeffrey suggested: > > the longer indeterminate durations are evaluated before the shorter ones. If > > an indeterminate duration must be converted to a determinate one (asSeconds) > > we use an average value such as 30 days in a month. In the context of > > Duration arithmetic against a TimeStamp, however, the indeterminate Duration > > is converted exactly. Our TimeStamps are also always in Universal > > Coordinated Time (UTC), allowing us to convert them to a user specified > > timezone for display. > > I would like to see this other classes if possible. I just wrote something > similar. And I found that for my needs storing the timestamp in local time not > gmt produced less conversion. Basically speaking, almost always the time stamp > is displayed and compared based on its local time. Rarely on its GMT time. Unfortunately, the classes can't be shared. Actually, they're not that beautiful and could definitely use some refactoring, but they work fine and hardly ever get changed. You're right that timeStamps almost always get displayed in local time. We decided for comparisons and sorting purposes to use UCT. We wanted audit trails to always be 'stamped' 'in order' regardless of which time zone work was done from and to only worry about the various world-wide daylight savings time rules at display time. If our time stamps were in local time we would still have to do a conversion of some sort anyway to handle the 'time goes backwards' problem for the night when daylight savings time ends. Doug |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
15 posts
|
In reply to this post by Ian Bartholomew-4
Ian, Richard,
What is the status with your implementation of DateAndTime and Duration ? Next week I have a few time to work on this. How can I help ? Peraps I can make some unit testing on your work. Have a nice day. Alain |
Free forum by Nabble | Edit this page |