TimeSpan Convenience

Discussion in 'Java' started by Josef Pfleger, Dec 3, 2006.

  1. helo,

    What is best-practise to achieve functionality similar to .Net's
    System.TimeSpan struct in Java?

    For now, I've created my own TimeSpan class
    (http://blog.orange-cactus.org/?p=24) but I wonder what Java-pro's use
    everyday?

    josef
     
    Josef Pfleger, Dec 3, 2006
    #1
    1. Advertising

  2. Josef Pfleger wrote:
    > helo,
    >
    > What is best-practise to achieve functionality similar to .Net's
    > System.TimeSpan struct in Java?
    >
    > For now, I've created my own TimeSpan class
    > (http://blog.orange-cactus.org/?p=24) but I wonder what Java-pro's use
    > everyday?
    >
    > josef


    Some similar functionality can be found in

    javax.xml.datatype.Duration

    which is part of Java 5 (aka 1.5).

    Also look at Joda Time:

    http://joda-time.sourceforge.net/
     
    Mark Thornton, Dec 3, 2006
    #2
    1. Advertising

  3. Josef Pfleger

    Chris Smith Guest

    > Josef Pfleger wrote:
    > > What is best-practise to achieve functionality similar to .Net's
    > > System.TimeSpan struct in Java?


    Store time spans as long. Format them using Calendar. Incidentally,
    there is no way the code at your link can be correct. In general, it is
    impossible to phrase a time interval in days (or any larger unit)
    without knowing the starting time, as well as the interval. For
    example, in localities that use daylight savings time, an interval of 23
    hours is less than a day most of the time, but it's exactly a day when
    it begins immediately prior to the beginning of daylight savings time.
    Any interval that spans either DST boundary will be similarly affected.
    There are other concerns as well, but that's the obvious one.

    Mark Thornton <> wrote:
    > javax.xml.datatype.Duration


    That appears to be a correct implementation.

    --
    Chris Smith
     
    Chris Smith, Dec 3, 2006
    #3
  4. Chris Smith wrote:
    >>Josef Pfleger wrote:
    >>
    >>>What is best-practise to achieve functionality similar to .Net's
    >>>System.TimeSpan struct in Java?

    >
    >
    > Store time spans as long. Format them using Calendar. Incidentally,
    > there is no way the code at your link can be correct. In general, it is
    > impossible to phrase a time interval in days (or any larger unit)
    > without knowing the starting time, as well as the interval.


    Just because the duration is variable doesn't mean the period is
    meaningless. For example, I like most in the UK, get paid monthly. So as
    the length of calendar months varies, so too does the duration between
    pay packets. Joda time describes this concept as a "period" as opposed
    to a duration (which always is an exact number of milliseconds in legth)
    or an interval which is the time between two specific instants.

    I haven't looked closely enough at the .NET class to determine which
    concept(s) it corresponds to.

    Mark Thornton
     
    Mark Thornton, Dec 3, 2006
    #4
  5. Josef Pfleger

    Chris Smith Guest

    Mark Thornton <> wrote:
    > Chris Smith wrote:
    > > Incidentally,
    > > there is no way the code at your link can be correct. In general, it is
    > > impossible to phrase a time interval in days (or any larger unit)
    > > without knowing the starting time, as well as the interval.

    >
    > Just because the duration is variable doesn't mean the period is
    > meaningless.


    Absolutely. I was commenting on the code at the link posted. It is an
    object that is initialized with a long (time interval in milliseconds),
    and contains methods to get days, hours, and minutes from there. I
    merely pointed out that it must be wrong sometimes.

    --
    Chris Smith
     
    Chris Smith, Dec 3, 2006
    #5
  6. Mark Thornton wrote:
    > I haven't looked closely enough at the .NET class to determine which
    > concept(s) it corresponds to.


    It corresponds to the period concept, thus storing a TimeSpan *only* as
    a number of ticks (1 tick equals 100 nanoseconds), nothing else,
    especially no starting point referring to a calendar.


    Chris Smith wrote:
    > I was commenting on the code at the link posted. It is an
    > object that is initialized with a long (time interval inmilliseconds),
    > and contains methods to get days, hours, and minutes from there. I
    > merely pointed out that it must be wrong sometimes.


    Since we have established to differ periods and timespans from durations
    or intervals, I have to say that my code at the link posted implements
    the period concept and is therefore correct and equal to .NET's TimeSpan
    structure. The only difference: It stores milliseconds rather than ticks.
    There are a lot of situations where this makes sense. For example, my
    long-haul flight will always last 26 hours and 21 minutes, no matter how
    many timezones I cross or in what century the destination country
    decided to introduce DST.

    Josef
     
    Josef Pfleger, Dec 16, 2006
    #6
  7. Josef Pfleger

    Chris Smith Guest

    Josef Pfleger <> wrote:
    > Since we have established to differ periods and timespans from durations
    > or intervals, I have to say that my code at the link posted implements
    > the period concept and is therefore correct and equal to .NET's TimeSpan
    > structure.


    > For example, my long-haul flight will always last 26 hours and 21 minutes,
    > no matter how many timezones I cross or in what century the destination
    > country decided to introduce DST.


    The code at the link you posted said:

    TimeSpan rem = new TimeSpan(
    System.currentTimeMillis() - xmas.getTimeInMillis());

    System.out.printf("%d days, %d hours and %d minutes till xMas ;-)",
    rem.getDays(), rem.getHours(), rem.getMinutes());

    It's the days that cause the problem. You can easily get seconds,
    minutes, and hours from calculations on the number of milliseconds, but
    days depends on the starting time and DST conventions. So no, that code
    is not correct.

    --
    Chris Smith
     
    Chris Smith, Dec 17, 2006
    #7
  8. Chris Smith wrote:
    > Josef Pfleger <> wrote:
    >
    >>Since we have established to differ periods and timespans from durations
    >>or intervals, I have to say that my code at the link posted implements
    >>the period concept and is therefore correct and equal to .NET's TimeSpan
    >>structure.

    >
    >
    >>For example, my long-haul flight will always last 26 hours and 21 minutes,
    >>no matter how many timezones I cross or in what century the destination
    >>country decided to introduce DST.

    >
    >
    > The code at the link you posted said:
    >
    > TimeSpan rem = new TimeSpan(
    > System.currentTimeMillis() - xmas.getTimeInMillis());
    >
    > System.out.printf("%d days, %d hours and %d minutes till xMas ;-)",
    > rem.getDays(), rem.getHours(), rem.getMinutes());
    >
    > It's the days that cause the problem. You can easily get seconds,
    > minutes, and hours from calculations on the number of milliseconds, but
    > days depends on the starting time and DST conventions. So no, that code
    > is not correct.


    If I were implementing this stuff:
    a) I'd use a number of milliseconds as the internal representation of a
    time interval or duration.
    b) Date objects would internally wrap milliseconds since the epoch, in a
    long, and be UTC. To get a localized date it would be interpreted
    relative to a Locale to get its date and time in a particular time zone.
    Localization of dates would be a peripheral thing; the core data would
    all be in UTC, and you could compare and find that the current date in
    london and the same date in new york were equal even though they printed
    differently, etc. There'd be separate Date (UTC) and LocalizedDate classes.
    c) Failing b), I'd have all calculations internally change incoming
    dates to UTC and results to the desired locale. Date parameters would be
    accompanyable by optional Locale objects and without them interpreted
    relative to the system locale.
     
    John Ersatznom, Dec 17, 2006
    #8
  9. Josef Pfleger

    Chris Smith Guest

    John Ersatznom <> wrote:
    > If I were implementing this stuff:
    > a) I'd use a number of milliseconds as the internal representation of a
    > time interval or duration.
    > b) Date objects would internally wrap milliseconds since the epoch, in a
    > long, and be UTC. To get a localized date it would be interpreted
    > relative to a Locale to get its date and time in a particular time zone.
    > Localization of dates would be a peripheral thing; the core data would
    > all be in UTC, and you could compare and find that the current date in
    > london and the same date in new york were equal even though they printed
    > differently, etc. There'd be separate Date (UTC) and LocalizedDate classes.
    > c) Failing b), I'd have all calculations internally change incoming
    > dates to UTC and results to the desired locale. Date parameters would be
    > accompanyable by optional Locale objects and without them interpreted
    > relative to the system locale.


    Good news! That's exactly how it works. Instead of LocalizedDate, we
    have Calendar (and TimeZone; each calendar has a time zone implicitly
    associated with it). All of the methods of java.util.Date that depend
    on localization were deprecated in the Java 1.1 release cycle. in 1998.
    Date does track dates in absolute time in UTC, and Calendar can be used
    to convert that to dates and times in any given locale. It all works
    fine.

    This thread appears to have originated because someone wanted an easier
    interface for it, and the interface was simplified too much by
    eliminating any knowledge of the beginning of a time interval or locale-
    specific information, which is important if you want to express the
    interval in days or any unit dependent on days.

    --
    Chris Smith
     
    Chris Smith, Dec 17, 2006
    #9
  10. Chris Smith wrote:
    > This thread appears to have originated because someone wanted an easier
    > interface for it, and the interface was simplified too much by
    > eliminating any knowledge of the beginning of a time interval or locale-
    > specific information, which is important if you want to express the
    > interval in days or any unit dependent on days.


    For a generic duration object, you'd use the approximation of 1 day ~=
    86400 seconds when expressing it in the UI, and internally it would just
    be a number of msec.

    All of what I wrote in this thread being intended for any similar
    situation arising in any language (and any alternative implementations
    in Java *cough*java.sql.Date*cough* ...)
     
    John Ersatznom, Dec 17, 2006
    #10
  11. Josef Pfleger

    Chris Smith Guest

    John Ersatznom <> wrote:
    > For a generic duration object, you'd use the approximation of 1 day ~=
    > 86400 seconds when expressing it in the UI, and internally it would just
    > be a number of msec.


    I would? I suppose I would do that with days or years only if that
    level of precision really didn't matter, and I'd document it since I'm
    really giving the wrong answer.

    --
    Chris Smith
     
    Chris Smith, Dec 17, 2006
    #11
  12. Chris Smith wrote:
    > It's the days that cause the problem. You can easily get seconds,
    > minutes, and hours from calculations on the number of milliseconds,
    > but days depends on the starting time and DST conventions.


    So it seems that the definition of the word 'day' has become the point
    of interest here. According to the first definition in the Oxford
    English Dictionary, a day is "a period of twenty-four hours as a unit of
    time, reckoned from midnight to midnight and corresponding to a rotation
    of the earth on its axis".
    http://www.askoxford.com/concise_oed/day?view=uk

    Obviously, Microsoft implemented a day as a fixed unit of time according
    to this definition in it's System.TimeSpan structure. So did I at the
    link posted and this is why I'm still convinced that my code is correct ;-)

    I realize that there are other definitions out there (some may include
    DST and timezone issues) but I aimed for a simpler interface and was
    basically imitating Microsoft's implementation.

    - Josef
     
    Josef Pfleger, Dec 23, 2006
    #12
  13. Josef Pfleger

    Lew Guest

    Josef Pfleger wrote:
    > So it seems that the definition of the word 'day' has become the point
    > of interest here. According to the first definition in the Oxford
    > English Dictionary, a day is "a period of twenty-four hours as a unit of
    > time, reckoned from midnight to midnight and corresponding to a rotation
    > of the earth on its axis".
    > http://www.askoxford.com/concise_oed/day?view=uk


    This definition is self-inconsistent for days when there is a timezone change,
    because the period from midnight to midnight will not be twenty-four hours.
    Which part of this particular definition should we invalidate?

    http://www.unc.edu/~rowlett/units/dictD.html
    gives three separate definitions.

    - Lew
     
    Lew, Dec 23, 2006
    #13
  14. Lew wrote:
    > This definition is self-inconsistent for days when there is a timezone
    > change, because the period from midnight to midnight will not be
    > twenty-four hours.

    I agree that timezone or DST borders are not explicitly mentioned. But
    it does refer to the rotation of the earth on its axis which gives a
    hint that they are defining the 'mean solar day', which is 24 hours long.

    > http://www.unc.edu/~rowlett/units/dictD.html

    Ok, so what I implemented is the 'mean solar day'. Thank you for the
    clarification. I will document it accordingly.
     
    Josef Pfleger, Dec 23, 2006
    #14
  15. Josef Pfleger wrote:
    > Chris Smith wrote:
    > > It's the days that cause the problem. You can easily get seconds,
    > > minutes, and hours from calculations on the number of milliseconds,
    > > but days depends on the starting time and DST conventions.

    >
    > So it seems that the definition of the word 'day' has become the point
    > of interest here. According to the first definition in the Oxford
    > English Dictionary, a day is "a period of twenty-four hours as a unit of
    > time, reckoned from midnight to midnight and corresponding to a rotation
    > of the earth on its axis".
    > http://www.askoxford.com/concise_oed/day?view=uk


    And what of the midnight to midnight bit? How many days in a 24 hour
    period starting at midday?

    Mark Thornton
     
    Mark Thornton, Dec 23, 2006
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. VB Programmer

    Question: TimeSpan

    VB Programmer, Jul 14, 2004, in forum: ASP .Net
    Replies:
    3
    Views:
    436
    Hans Kesting
    Jul 15, 2004
  2. =?Utf-8?B?S2VubmV0aCBQ?=

    Using TimeSpan or Elapsed e.t.c. Methods

    =?Utf-8?B?S2VubmV0aCBQ?=, Nov 6, 2004, in forum: ASP .Net
    Replies:
    5
    Views:
    1,420
    =?Utf-8?B?S2VubmV0aCBQ?=
    Nov 7, 2004
  3. Rosanne

    TimeSpan problem

    Rosanne, Jul 19, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    520
    Eliyahu Goldin
    Jul 20, 2005
  4. Harry Haller
    Replies:
    0
    Views:
    3,429
    Harry Haller
    Jul 21, 2005
  5. Clive

    Timespan calculations

    Clive, Aug 28, 2003, in forum: C++
    Replies:
    3
    Views:
    4,132
    Clive
    Sep 8, 2003
Loading...

Share This Page