Implement PlainTime

[ashutoshvarma]

Part of #21

• PlainTime
  • compare (add PlainTime basics #8)
  • equals (add PlainTime basics #8)
  • from
  • add
  • subtract
  • toString
  • with
  • until
  • since
  • round
  • toJSON
  • valueOf
  • toPlainDateTime

Other fixes include in PR

• fix PlainDateTime.fromString for "1976-11-18T15:23:30.1Z" family [2d0abd5]
• fix PlainDateTime.fromString for "1976-11-18T152330.1+00:00" family [73b57ec]
• fix balanceDuration() is broken when when largestUnit is greater than TimeComponent.days  #29 : balanceDuration() for largestUnit greater than Days [5c36d22]
• fix Duration.toString() for negative values [6cc1621]
• fix trailing zero in Duration.toString()

[ashutoshvarma]

From failing tests log, seems FP rounding error

[Fail]: ✖ 15:23:30.123456789.add({ nanoseconds: 300 })
[Actual]: "15:23:30.12345708899999999"
[Expected]: "15:23:30.123457089"

How should we handle floating-point rounding errors?

[MaxGraey]

How should we handle floating-point rounding errors?

Such imprecise rarely happens in dtoa implementaion in AS. I have plan rewrite that to more modern Ryu's implementation. But currently we could just ignore this imprecision and add some TODO comment

[ashutoshvarma]

@MaxGraey shouldn't it be 8 instead of 4 in sign ? or am I missing something?

assemblyscript-temporal/assembly/utils.ts

Lines 177 to 181 in 1d02f91

	export function sign<T extends number>(x: T): T {
	// x < 0 ? -1 : 1 -> x >> 31 | 1
	// @ts-ignore
	return (x >> (sizeof<T>() * 4 - 1)) | 1;
	}

[MaxGraey]

right! Good catch!

[ashutoshvarma]

Also while working on util(), I get to know that balanceDuration is broken when largestUnit is greater than TimeComponent.days .

I will create an issue for it shortly

[ashutoshvarma]

right! Good catch!

Should I add a commit for it in this PR ? PlainTime.until() tests are failing because of it too

[MaxGraey]

I already made PR with fix: #28

[ashutoshvarma]

assemblyscript-temporal/assembly/duration.ts

Lines 71 to 78 in 1d02f91

	toString(
	// sort in ascending order for better sum precision
	f64(this.nanoseconds) / 1000000000.0 +
	f64(this.microseconds) / 1000000.0 +
	f64(this.milliseconds) / 1000.0 +
	f64(this.seconds),
	"S"
	);

@MaxGraey is there a way to remove the trailing .0 from the f64 string representation? I tried reparsing string back using parseFloat and then toString but it didn't work

From CI logs https://github.com/ColinEberhardt/assemblyscript-temporal/runs/2270205795

[Fail]: ✖ the default largest unit is at least hours
[Actual]: "PT6H52M42.0S"
[Expected]: "PT6H52M42S"

[MaxGraey]

is there a way to remove the trailing .0 from the f64 string representation? I tried reparsing string back using

Trailing zero for serialized f64/f32 strings is a deliberate decision and convention of AssemblyScript which differ from JS/TS. So I suggest slightly modify original tests and add .0 when this required

[ashutoshvarma]

I think this PR is good to go now!

[MaxGraey]

is there a way to remove the trailing .0 from the f64 string representation? I tried reparsing string back using

Trailing zero for serialized f64/f32 strings is a deliberate decision and convention of AssemblyScript which differ from JS/TS. So I suggest slightly modify original tests and add .0 when this required

Another option:

function stringify(value: f64): string {
   return F64.isSafeInteger(value) ? i64(value).toString() : value.toString();
}

[ashutoshvarma]

function stringify(value: f64): string {
   return F64.isSafeInteger(value) ? i64(value).toString() : value.toString();
}

This is great! With this Duration.toString() will be more close to tc39 implementation

[ColinEberhardt]

I think this PR is good to go now!

Thank you - great work 👍

[github-actions]

🎉 This PR is included in version 1.3.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀