[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.javascript

about-time Time, Duration, and TimeSpan library updated

Simon Blackwell

1/9/2016 2:17:00 PM

About-time is Javascript browser and server library for managing, comparing, and doing arithmetic on Time, Duration, TimeSpan objects in manners similar to and beyond those provided by Date.

Time supports all the methods supported by Date, declarative access to all get and set values, e.g. */<instance/>.fullYear* is the same as getFullYear(), and adds the capability to represent only a specific precision, e.g. "Y", "M", "h", plus the ability to determine if it is within a given TimeSpan.

Durations are stored as milliseconds but may be Infinite in length and provide access at the typically useful levels of seconds, minutes, hours, days, weeks, months, quarters, years. Durations support arithmetic manipulation and can also be compared at varying precisions.

TimeSpans are stored as starting and ending milliseconds which include -Infinity and Infinity. They support comparisons with other TimeSpans and Times such as before, after, intersection, coincident, and disjoint.

The library is available at https://github.com/anywhichway/... or via https://www.npmjs.com/package/....
5 Answers

Michael Haufe (\"TNO\")

1/10/2016 12:32:00 AM

0

On Saturday, January 9, 2016 at 8:16:53 AM UTC-6, Simon Blackwell wrote:
> About-time is Javascript browser and server library for managing, comparing, and doing arithmetic on Time, Duration, TimeSpan objects in manners similar to and beyond those provided by Date.
>
> Time supports all the methods supported by Date, declarative access to all get and set values, e.g. */<instance/>.fullYear* is the same as getFullYear(), and adds the capability to represent only a specific precision, e.g. "Y", "M", "h", plus the ability to determine if it is within a given TimeSpan.
>
> Durations are stored as milliseconds but may be Infinite in length and provide access at the typically useful levels of seconds, minutes, hours, days, weeks, months, quarters, years. Durations support arithmetic manipulation and can also be compared at varying precisions.
>
> TimeSpans are stored as starting and ending milliseconds which include -Infinity and Infinity. They support comparisons with other TimeSpans and Times such as before, after, intersection, coincident, and disjoint.
>
> The library is available at https://github.com/anywhichway/... or via https://www.npmjs.com/package/....

Have you made any efforts regarding legacy/conflicting calendar issues?

One example:

In 1918 The Soviet Union moved from the Julian to Gregorian calendar. During this transition January 31 was followed by February 14.

There are numerous more as well. Is this something that matters for you or your users?

Simon Blackwell

1/10/2016 10:53:00 AM

0

On Saturday, January 9, 2016 at 7:32:34 PM UTC-5, Michael Haufe (TNO) wrote:
> On Saturday, January 9, 2016 at 8:16:53 AM UTC-6, Simon Blackwell wrote:
> > About-time is Javascript browser and server library for managing, comparing, and doing arithmetic on Time, Duration, TimeSpan objects in manners similar to and beyond those provided by Date.
> >
> > Time supports all the methods supported by Date, declarative access to all get and set values, e.g. */<instance/>.fullYear* is the same as getFullYear(), and adds the capability to represent only a specific precision, e.g.. "Y", "M", "h", plus the ability to determine if it is within a given TimeSpan.
> >
> > Durations are stored as milliseconds but may be Infinite in length and provide access at the typically useful levels of seconds, minutes, hours, days, weeks, months, quarters, years. Durations support arithmetic manipulation and can also be compared at varying precisions.
> >
> > TimeSpans are stored as starting and ending milliseconds which include -Infinity and Infinity. They support comparisons with other TimeSpans and Times such as before, after, intersection, coincident, and disjoint.
> >
> > The library is available at https://github.com/anywhichway/... or via https://www.npmjs.com/package/....
>
> Have you made any efforts regarding legacy/conflicting calendar issues?
>
> One example:
>
> In 1918 The Soviet Union moved from the Julian to Gregorian calendar. During this transition January 31 was followed by February 14.
>
> There are numerous more as well. Is this something that matters for you or your users?

We have not. However, the algorithms for converting between Julian and Gregorian are readily available, e.g. http://aa.usno.navy.mil/faq/docs/JD_F..., and we could.

Under the assumption you are or could be a user, this matters. We have not had to deal with it for our clients.


It would seem the best place to add this capability would be Time, by changing its constructor signature to Time(value,precision="ms",calendar="G").

We could also have a method Time.prototype.toCalendar(calendar,modify=true) which would return a modified or new Time converted from the current calendar to the new one.

Would the above be adequate?

Are there calendars other than Julian and Gregorian you think we should support, e.g Hebrew?

Finally, if you have to prioritize features which would you want:

1) calendar conversion
2) time service synch capability, i.e. ensure accurate time for the local compute context
3) time zone conversions

Michael Haufe (\"TNO\")

1/10/2016 10:50:00 PM

0

On Sunday, January 10, 2016 at 4:53:43 AM UTC-6, Simon Blackwell wrote:

> Under the assumption you are or could be a user, this matters. We have not had to deal with it for our clients.

I would not be one of your clients. I already have a library for date and time manipulation based on the efforts of J.R. Stockton[1] and others.

> It would seem the best place to add this capability would be Time, by changing its constructor signature to Time(value,precision="ms",calendar="G").
>
> We could also have a method Time.prototype.toCalendar(calendar,modify=true) which would return a modified or new Time converted from the current calendar to the new one.
>
> Would the above be adequate?

That would depend on your target usage and library consumers.

> Are there calendars other than Julian and Gregorian you think we should support, e.g Hebrew?

Personally, I am indifferent. Have you compared your library to others in use in JavaScript at this point?

> Finally, if you have to prioritize features which would you want:
>
> 1) calendar conversion
> 2) time service synch capability, i.e. ensure accurate time for the local compute context
> 3) time zone conversions

#2 seems a strange feature. Do you have an example?

[1]<https://web.archive.org/web/20150514050046/http://www.merlyn.demon.co.uk/contents.h...

Dr J R Stockton

1/11/2016 8:57:00 PM

0

In comp.lang.javascript message <473a3ab3-1f5c-4bae-9e0b-63ebc92f9826@go
oglegroups.com>, Sun, 10 Jan 2016 02:53:08, Simon Blackwell
<syblackwell@anywhichway.com> posted:

>3) time zone conversions

Please be careful to honour the proper definition of Time Zone. A Time
Zone is the set of places for which Standard Local Time (and Date) is
the same; and Standard Local Time is Winter Time (whether centred about
January or July). Summer Time, where it is used, is advanced from
Winter/Standard Time by a half or one hour, and does not affect Time
Zone at all. Remember too that in the 'forties the British Isles, or at
least the UK, sometimes used Double Summer Time.

New York, USA, use EST as a Winter offset indicator and EDT as a summer
one, and (more rarely) uses ET to indicate New York Local Civil Time
(LCT).

Actually, in some places LCT is officially governed by GMT and in others
it is governed by UTC - that difference is ignored in considering the
Time Zone.

Note that there is a region where the date of the end of Summer Time is
sometimes affected by the Date of Easter Sunday.

I have code to transfer date/time between any two locations for which an
M-type TZ string can be given. Use The Wayback Machine for site
merlyn.demon.co.uk.

Do not check your Week Number code, if any, against Microsoft DatePart,
except for purposes of amusement.

See Wikipedia, BIPM?, NPL, NIST, etc.

--
(c) John Stockton, Surrey, UK. ¬@merlyn.demon.co.uk Turnpike v6.05 MIME.
Merlyn Web Site < > - FAQish topics, acronyms, & links.

Simon Blackwell

1/11/2016 10:41:00 PM

0

On Sunday, January 10, 2016 at 5:50:04 PM UTC-5, Michael Haufe (TNO) wrote:
> On Sunday, January 10, 2016 at 4:53:43 AM UTC-6, Simon Blackwell wrote:
>
> > Under the assumption you are or could be a user, this matters. We have not had to deal with it for our clients.
>
> I would not be one of your clients. I already have a library for date and time manipulation based on the efforts of J.R. Stockton[1] and others.
>
> > It would seem the best place to add this capability would be Time, by changing its constructor signature to Time(value,precision="ms",calendar="G").
> >
> > We could also have a method Time.prototype.toCalendar(calendar,modify=true) which would return a modified or new Time converted from the current calendar to the new one.
> >
> > Would the above be adequate?
>
> That would depend on your target usage and library consumers.
>
> > Are there calendars other than Julian and Gregorian you think we should support, e.g Hebrew?
>
> Personally, I am indifferent. Have you compared your library to others in use in JavaScript at this point?

We did research into other libraries prior to writing about-time. The challenge was we needed something that supported the following:

- a common application development approach across date, time, and duration
- a declarative approach that was easy to persist and restore

We considered wrapping a couple of libraries, but for our needs the effort was too high. That being said, our needs were not as precise as those that JR Stockton might advocate and not as broad ranging at the date level as say moment.js. We may re-consider this going forward with the recognition that the testing load on a more extensive library that is fully our own may get high. However, our plan would be to preserve the declarative approach to ensure compatibility with JOQULAR.

>
> > Finally, if you have to prioritize features which would you want:
> >
> > 1) calendar conversion
> > 2) time service synch capability, i.e. ensure accurate time for the local compute context
> > 3) time zone conversions
>
> #2 seems a strange feature. Do you have an example?

With respect to item #2, if time/date calculations are persisted to a database and potentially calculated on different machines then it would be important that the functions doing the computation ensure they are in sync with some centralized source prior to doing the computation.

Thanks for the dialogue on this.

>
> [1]<https://web.archive.org/web/20150514050046/http://www.merlyn.demon.co..uk/contents.h...