@brightspace-ui/intl - npm Package Compare versions

Comparing version 3.1.4 to 3.2.0

lib/dateTime.js

@@ -299,2 +299,19 @@ import { getDocumentLocaleSettings, getLanguage, merge } from './common.js';
 
+function convertJsDateToLocalDateTime(utcDate) {
+	const formattedDateTime = formatDateString(utcDate);
+	const re = /([0-9]{1,2})\/([0-9]{1,2})\/([0-9]{4})( |, )([0-9]{1,2}):([0-9]{2}):([0-9]{2})/;
+	const match = formattedDateTime.match(re);
+	if (!match || match.length !== 8) {
+		return null;
+	}
+	return {
+		month: parseInt(match[1]),
+		date: parseInt(match[2]),
+		year: parseInt(match[3]),
+		hours: parseInt(match[5]),
+		minutes: parseInt(match[6]),
+		seconds: parseInt(match[7])
+	};
+}
+
 function formatDateString(date) {
@@ -631,16 +648,3 @@ const timezone = getDocumentLocaleSettings().timezone.identifier;
 	const utcDate = new Date(Date.UTC(date.year, date.month - 1, date.date, date.hours, date.minutes, date.seconds));
-	const formattedDateTime = formatDateString(utcDate);
-	const re = /([0-9]{1,2})\/([0-9]{1,2})\/([0-9]{4})( |, )([0-9]{1,2}):([0-9]{2}):([0-9]{2})/;
-	const match = formattedDateTime.match(re);
-	if (!match || match.length !== 8) {
-		return date;
-	}
-	return {
-		month: parseInt(match[1]),
-		date: parseInt(match[2]),
-		year: parseInt(match[3]),
-		hours: parseInt(match[5]),
-		minutes: parseInt(match[6]),
-		seconds: parseInt(match[7])
-	};
+	return convertJsDateToLocalDateTime(utcDate) || date;
 }
@@ -1118,1 +1122,9 @@
 }
+
+export function formatDateTimeFromTimestamp(timestamp, options) {
+	const utcDate = new Date(timestamp);
+	const local = convertJsDateToLocalDateTime(utcDate);
+	if (!local) return formatDateTime(utcDate, options);
+	const localDate = new Date(local.year, local.month - 1, local.date, local.hours, local.minutes, local.seconds);
+	return formatDateTime(localDate, options);
+}

package.json

 {
   "name": "@brightspace-ui/intl",
-  "version": "3.1.4",
+  "version": "3.2.0",
   "description": "Internationalization APIs for number, date, time and file size formatting and parsing in D2L Brightspace.",
@@ -5,0 +5,0 @@ "main": "lib/number.js",

README.md

@@ -81,2 +81,4 @@ # intl
 
+Timestamps (milliseconds since the epoch) can be formatted in the user's locale and timezone using `formatDateTimeFromTimestamp`.
+
 Combined dates and times are formatted using `formatDateTime`:
@@ -99,2 +101,14 @@
 
+To format a **timestamp** as a date and time:
+
+```javascript
+const dateString = formatDateTimeFromTimestamp(
+	1607097863123,
+	[options]
+);
+```
+
+Options are the same as for `formatDateTime`; this method converts the timestamp to a `Date` in the user's
+configured time zone, then returns the results of passing this date to `formatDateTime`.
+
 To format a **date only** (without the time portion), use `formatDate`:
@@ -216,10 +230,39 @@
 
-## Versioning, Releasing & Deploying
+## Versioning & Releasing
 
-All version changes should obey [semantic versioning](https://semver.org/) rules.
+> TL;DR: Commits prefixed with `fix:` and `feat:` will trigger patch and minor releases when merged to `master`. Read on for more details...
 
-Releases use the [semantic-release](https://semantic-release.gitbook.io/) tooling and the [angular preset](https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-changelog-angular) for commit message syntax. Upon release, the version in `package.json` is updated, a tag and GitHub release is created and a new package will be deployed to NPM.
+The [sematic-release GitHub Action](https://github.com/BrightspaceUI/actions/tree/master/semantic-release) is called from the `release.yml` GitHub Action workflow to handle version changes and releasing.
 
-Commits prefixed with `feat` will trigger a minor release, while `fix` or `perf` will trigger a patch release. A commit containing `BREAKING CHANGE` will cause a major release to occur.
+### Version Changes
 
-Other useful prefixes that will not trigger a release: `build`, `ci`, `docs`, `refactor`, `style` and `test`. More details in the [Angular Contribution Guidelines](https://github.com/angular/angular/blob/master/CONTRIBUTING.md#type).
+All version changes should obey [semantic versioning](https://semver.org/) rules:
+1. **MAJOR** version when you make incompatible API changes,
+2. **MINOR** version when you add functionality in a backwards compatible manner, and
+3. **PATCH** version when you make backwards compatible bug fixes.
+
+The next version number will be determined from the commit messages since the previous release. Our semantic-release configuration uses the [Angular convention](https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-changelog-angular) when analyzing commits:
+* Commits which are prefixed with `fix:` or `perf:` will trigger a `patch` release. Example: `fix: validate input before using`
+* Commits which are prefixed with `feat:` will trigger a `minor` release. Example: `feat: add toggle() method`
+* To trigger a MAJOR release, include `BREAKING CHANGE:` with a space or two newlines in the footer of the commit message
+* Other suggested prefixes which will **NOT** trigger a release: `build:`, `ci:`, `docs:`, `style:`, `refactor:` and `test:`. Example: `docs: adding README for new component`
+
+To revert a change, add the `revert:` prefix to the original commit message. This will cause the reverted change to be omitted from the release notes. Example: `revert: fix: validate input before using`.
+
+### Releases
+
+When a release is triggered, it will:
+* Update the version in `package.json`
+* Tag the commit
+* Create a GitHub release (including release notes)
+* Deploy a new package to NPM
+
+### Releasing from Maintenance Branches
+
+Occasionally you'll want to backport a feature or bug fix to an older release. `semantic-release` refers to these as [maintenance branches](https://semantic-release.gitbook.io/semantic-release/usage/workflow-configuration#maintenance-branches).
+
+Maintenance branch names should be of the form: `+([0-9])?(.{+([0-9]),x}).x`.
+
+Regular expressions are complicated, but this essentially means branch names should look like:
+* `1.15.x` for patch releases on top of the `1.15` release (after version `1.16` exists)
+* `2.x` for feature releases on top of the `2` release (after version `3` exists)

No alert changes

Improved metrics

Total package byte prevSize

68903

increased by3.89%

Lines of code

1544

increased by0.65%

Number of lines in readme file

266

increased by19.28%

No dependency changes