spencermountain / spacetime Goto Github PK

It seems that the DST "change" property it's not rightly handled in the southern hemisphere.

For example, if you set as date 2017-10-09 12:00 UTC and go to America/Sao_Paulo timezone, hour() method should return 09:00 because (ref):

• UTC standard offset is -3;
• UTC DST offset is -2;
• DST starts on october 15th

Coherently, if you change date to 2017-10-16 it should return as 10:00.

At this line the dst.change is constantly set to -60, but in the case above it should be +60.

Indeed, the timezone().offsets property returns {base: -240, dst: -180} instead of {base: -180, dst: -120}

Same happens with America/Campo_Grande and America/Cuiaba.

I can't understand if this pattern (inverse of current dst.change) could be applied to every timezone in the southern hemisphere.

Take a look to this repl

Hi, I tested the following code：

console.log(spacetime('2018-02-02T22:00:00'))
console.log(spacetime('2018-02-02 22:00:00'))

The first line, I get:

{tz: "Asia/Shanghai", valid: true, epoch: 1517580000262}

The second line, I get:

Warning: couldn't parse date-string: '2018-02-02 22:00:00'
u @ spacetime.js?be0a:4
u @ spacetime.js?be0a:5
i @ spacetime.js?be0a:4
submitDiary @ Index.vue?2753:49
boundFn @ vue.esm.js?efeb:190
click @ Index.vue?1a5d:176
invoker @ vue.esm.js?efeb:2004
fn._withTask.fn._withTask @ vue.esm.js?efeb:1802
Index.vue?2753:49 u {tz: "Asia/Shanghai", valid: false, epoch: null}

Actually, for date strings, I use spaces as separators more often than ever. Do you think you can add this feature? Thank you.

Greetings, I was curious if implementing Moment's fromNow feature is in the roadmap? It seems like it wouldn't be too tough to do by leveraging diff.

Just thinking through the rough logic:

• Diff on years; if years >= 1, ${years} year(s) ago, else...
• Diff on months; if months >= 1, ${months} month(s) ago else...
• Et cetera.

Pluralization of the time unit would be handled, of course, and the logic Moment uses would be easy to duplicate.

If this is something you'd like to support, and the rough approach above sounds like the right path to you, I could do a bit of work and open a PR.

bug (from mexico city tz)

 let s = spacetime([2017, 5, 25]);
 s.quarter('q2')
 console.log(s.format('nice'))

should be April 1, but is March 31

tricky double-day bug:

///BUG:
let d = spacetime('2019-11-04T00:00:00.000')
let s = d
for (let i = 0; i < 7; i += 1) {
  console.log(s.format('date'))
  s = s.add(1, 'day')
}

d = d.add(1, 'week')
console.log('---')
for (let i = 0; i < 7; i += 1) {
  console.log(d.format('date'))
  d = d.add(1, 'day')
}
/*
4
5
6
7
8
9
10
---
10
11
12
13
14
15
16
*/

Hi, I'm playing with your package and I think that I found a problem with the returned epoch value. Here is the code:

var spacetime = require('spacetime');

var s1 = spacetime([2017, 9, 4, 10, 20, 0, 0], 'Europe/Madrid');
console.log("[spacetime] iso date: " + s1.format('iso') + "  epoch: " + s1.epoch);
console.log("[spacetime] tz name: " + s1.timezone().name);
console.log("[spacetime] offset: " + s1.timezone().current.offset);
console.log("[spacetime] isDst: " + s1.timezone().current.isDst);

// There is a DST change on 29-10-2017 at 03:00:00

var s2 = spacetime([2017, 9, 30, 10, 20, 0, 0], 'Europe/Madrid');
console.log("[spacetime] iso date: " + s2.format('iso') + "  epoch: " + s2.epoch);
console.log("[spacetime] tz name: " + s2.timezone().name);
console.log("[spacetime] offset: " + s2.timezone().current.offset);
console.log("[spacetime] isDst: " + s2.timezone().current.isDst);

And the output is:

[spacetime] iso date: 2017-10-04T10:20:00:000Z  epoch: 1507105200000
[spacetime] tz name: Europe/Madrid
[spacetime] offset: 120
[spacetime] isDst: true
[spacetime] iso date: 2017-10-30T10:20:00:000Z  epoch: 1509358800000
[spacetime] tz name: Europe/Madrid
[spacetime] offset: 60
[spacetime] isDst: false

If I use https://www.epochconverter.com/ with the first epoch (1507105200000) I see what I expect, the GMT value is: "GMT: Wednesday, October 4, 2017 8:20:00 AM" because there is a 120 offset.

But If I set the second epoch (1509358800000) the GMT value is unexpected: "GMT: Monday, October 30, 2017 10:20:00 AM". What I expect should be GMT: Monday, October 30, 2017 09:20:00 AM because there is a 60 offset.

There is a bug or I'm missing something?
Thanks

Not sure this is a bug or misunderstand the API.
"since" call seems to output some questionable result, please refer the screenshots below.

couldn't understand why it's '3 days 11 hours ago', since 'diff' with days only output -1

Please consider using git tags when making releases. Specially useful with Github release notifications.

Also can you also consider ordering changelolg from the most recent release to the older.

Thanks.

The ampm parameter of the object date input seems to default to pm when it's passed null or an empty string without a timezone. All the other params that I've tested seem to fallback to .now() values, but 'ampm' always defaults to pm, which seems a bit off, especially when null or a blank string are passed (I would expect am).

Here's what I tested:

spacetime({month:'12', day:'25', hour:'6', minute:'24', ampm:null}).format('nice')
/* and */
spacetime({month:'12', day:'25', hour:'6', minute:'24', ampm:''}).format('nice')

/* return "Dec 25th, 6:24pm" */

This is really obvious if you try to pass a 24h time:

spacetime({month:'12', day:'25', hour:'15', minute:'24', ampm:null}).format('nice')
/* and */
spacetime({month:'12', day:'25', hour:'15', minute:'24', ampm:''}).format('nice')

/* return "Dec 26th, 3:24am" */

If you add a timezone, or remove the ampm param altogether, it works as expected (defaults to am):

spacetime({month:'12', day:'25', hour:'15', minute:'24', ampm:null}, 'America/New_York').format('nice')
/* and */
spacetime({month:'12', day:'25', hour:'15', minute:'24'}).format('nice')

/* return "Dec 25th, 3:24pm" */

Yesterday straight after midnight (I am in timezone "Europe/Berlin") I started to see a strange bug when trying to add one week to certain dates. Examples 2018-10-22 and a few following days. This morning I don't have the problem, but when I jump to timezone "America/Adak" I managed to reproduce the bug.

Here you could see how adding a week to 21 of Oktober works fine, but on the day after only 6 days gets added: https://runkit.com/toreskog/5baea71a80fd230012a7930a

Hi there!! This is really neat! I was wondering if any of us at webpack could help ship this code over using ES Module Syntax?

Can include motivations if needed! 👨‍🔬🔥

from recurrent googling, seems the popular way to expose the api now is a .d.ts typings file, and pointing to it from package.json. I'm easy regarding any alternative formats.

moment tests it this way, which seems doable for us.
-thoughts @brianleroux ?

support
abbreviation to IANA.

PST -> Canada/Pacific etc.

may need to do it manually, i don't see it anywhere
(from #19 )

Hey I was using the unix format "MM d, h:mm a" and I would have expected it to read "Nov 7th, 11:05 am".

Instead I got "Nov 7th, 11:5 am". I checked through https://github.com/smallwins/spacetime/blob/master/src/methods/format/unixFmt.js and it looks like 'mm' and 'm' are equivalent, so I don't think I'm using the spec wrong.

create .unixFormat and ensure output equals moment.format's spec

move unix formatting out of format, that way we avoid crazy cruft of special characters and stuff.

maybe .format() should support .format('it is [time] o'clock') or something like that.

Open to proposals!

My impression is that its the timezone data that makes up most of the size of a library like this.

As a follow up to #37: Would it perhaps be possible to make the timezone data tree-shakeable? So that only the data for the time zones that one are actively referencing gets included?

If you're unfamiliar with the concept, then here's some more reading: https://webpack.js.org/guides/tree-shaking/ It do require ESM

moment and moment-timezone have great tests, and given that our apis are so similar, should take only a bit of elbow-grease to move some of these over

I would like to know how to escape "weird" unix-formatting

There is no indications in the doc https://github.com/spencermountain/spacetime/wiki/Formatting

PS: By the way the format (or any other method) doc on https://spencermountain.github.io/spacetime/ is useless and gives no informations 🤔

When i parse a date with the offset speficied, trying to format the date as iso or iso-utc swaps the offset operator from + to - and vice versa.

Example:
http://jsfiddle.net/w082uros/6/

311.pdf
Task4_6.311.RData.zip

Greetings!

I have an stidf (trajectory) element and I am trying to display it with an stplot() function, as described below. However:

Firstly, the cuts where I want the colors to change are not "understood" by the stplot().
Secondly, I am not sure how to show the coordinates on the graph.
Thirdly, the code shows an error message on the image: "error using packet, could not find function 'stidf'".
Finally, the "name.attr" argument does not respond.

Thank you for your attention! Best regards.

#Variable
fileMonth3<-311

load(paste0("Task4_6.",fileMonth3,".RData"));stidf_model<-stidf_SIMAR

#layout

m <- map2SpatialLines(map(database="world",xlim = c(-5,10),
ylim = c(32,46), plot =F))

proj4string(m) <- "+proj=longlat +datum=WGS84 +ellps=WGS84"

layout1 <- list(list("sp.lines", m, col = "gray"), list("stidf",stidf_model, first = FALSE, cex = 0.5))

#plot and save map

pdf(paste0("fileMonth3,".pdf"))

#plotting rHs

stplot(stidf_model[1:length(stidf_model@sp),1:nrow(stidf_model@time),2],
sp.layout=layout1,number=1,name.attr="var1.pred",
at=seq(-1,1,by=0.5))
dev.off()

So if I see it right this library doesn't use tz database full data that is used by https://momentjs.com/timezone/ and thus can not be used for historical dates, is spacetime intended only for current moment dates conversions?

Give the following snipet:

const spacetime = require('spacetime')
const date = spacetime('2019-02-16T23:14:34+01:00')
// date.d -> 2019-02-16T21:14:34.157Z !incorrect
// date.iso() -> 2019-02-16T23:14:34.157+01:00 correct
const otherDate = new Date(Date.parse(date.iso()))
// otherDate -> 2019-02-16T22:14:34.157Z correct

It seems that the .d property has some issues with (probably) the timezone? In any case, it's not a representation of the parsed date.

https://twitter.com/hopefulcyborg/status/856904772288466945

ht @afabbro

Sympton

> from = spacetime("2019-02-05 00:00:00")
SpaceTime { epoch: 1549278000878, tz: 'pacific/auckland', silent: true }
> from = spacetime("2019-02-05 00:00:00.0")
SpaceTime { epoch: 1549278000000, tz: 'pacific/auckland', silent: true }
> to = from.clone().minus(20, 'years')
SpaceTime { epoch: 918126000000, tz: 'pacific/auckland', silent: true }
> to.diff(from)
{ milliseconds: 631152000000,
  seconds: 631152000,
  minutes: 10519200,
  hours: 175320,
  years: 20,
  months: 240,
  weeks: 1047,
  days: 7305 }

Weeks should be 1043 instead of 1047

Cause

Week diff use climb way to adds weeks one by one until it reaches the target, the underlying adds function collects ms,sec,hour before the addition and then feeds them to the 'walk(s, want)' function to walk around and get precise match, but it could potentially step back for 23 hours rather than 1 hour while cross from non-dst to dst dates as shown in above, which cause the outer diff loop went more round and produce more week difference.

Root cause

ok, just found the root of this:

> a = spacetime('2018-03-29 00:00:0.0')
SpaceTime { epoch: 1522234800000, tz: 'pacific/auckland', silent: true }
> b = a.clone().add(1, 'week')
SpaceTime { epoch: 1522756800000, tz: 'pacific/auckland', silent: true }
> b.since(a)
{ diff:
   { years: 0, months: 0, days: 6, hours: 24, minutes: 0, seconds: 0 },
  rounded: '7 days ago',
  qualified: 'almost 7 days ago',
  precise: '6 days, 24 hours ago' }
> a.format('{mdy} {time-24}')
'03/29/2018 0:00'
> b.format('{mdy} {time-24}')
'04/04/2018 0:00'

it should be '04/04/2018 23:00' because dst instead of '0:00', the 'add' function actually step back for 23 hour.

Fix

• A 'dst compensate' step before it went for a 'walk'.
  - or just normal ms division instead of climb for 'week' diff

please @spencermountain, would like to hear your advise

definite need to fix the add & walk issue, should be come up a fix shortly

Hi,
After a couple of weeks of pausing, I just pulled a project I was working on that uses spacetime.
However, I keep getting "spacetime is not defined" regardless of using
<script src="https://unpkg.com/spacetime"></script>,
https://unpkg.com/[email protected]/builds/spacetime.min.js
or if src is a local file copied from that same URL
Any pointers? :/
Thanks a lot!

When trying to change time zone to:

• Asia/Tomsk
• Asia/Volgograd
• Coordinated Universal time +13

using .goto() it returns an error: Cannot read property 'dst' of undefined.

In the pictures below trying to load spacetime.how website after changing the computer's time zone to these 3 time zones and getting that error. Checked with all time zones provided with Windows 10 settings and only those three returned this error.

The season in the southern hemisphere is incorrectly being reported as being the same as the northern hemisphere.

Example:
It's currently winter in the southern hemisphere, but the library reports it as summer.

How about supporting isBetween api for checking if a date is in the range

var now = spacetime().now()
var start = spacetime('July 2, 2017 5:01:00')
var end = spacetime('July 2, 2018 5:01:00')

// return true or false
now.isBetween(start, end)

Is there a way to get abbreviation or full timezone name like "EST" or "Eastern Standard Time", for now I can only get "America/New_York".
ex:

const now = spacetime.now() 
now.goto('America_New_York')
now.timezone().format('zz')  
/*
returns 'America/New_York', is there a way for it to return 'EDT'/'EST' 
or 'Eastern Daylight Time'/'Eastern Standard Time'?
*/

Having a problem setting the time using immutable. Trying to set the time to 08:00, but for some reason it seems to be set to the current hour.

I reproduced the bug with runkit: https://runkit.com/toreskog/5ba7999d0612d500122fbb97

const spacetime = require("spacetime/immutable")

const day = spacetime('2018-09-23').time('06:00')
console.log(day.format('iso')) // --> "2018-09-23T15:00:00.000+02:00"

👇

for(let i = 0; i < 15; i++) {
  var s = spacetime({
    year: 2014 + i
  }).endOf('year');
  console.log(s.dayOfYear());
}

→ s.now('Australia/Brisbane').season('summer')//december!

const timestamp = '2017-04-03T08:00:00-0700'
const s = spacetime(timestamp)
const date = new Date(timestamp)

s.timezone().name
// "Europe/London"

s.hour()
// 8 

date.getUTCHours()
// 15 

Unless I'm missing something in how spacetime is supposed to be used, I can't see a way of telling the library that a) the date was in a different timezone to me or b) to somehow localize the datetime I gave it.

It appears here that you match for a timezone but then don't do anything with it (it would be arr[5]).

I'm happy to put in a PR but I wanted to check I wasn't misunderstanding what this library is supposed to do.

loving the lightweight timezone library, but i don't see a way to list all timezones.
you've got this whole data module, can we get a function to expose it?

spacetime.zones() perhaps?

set computer time to 7:30pm EST

console.log(spacetime('March 1st 2015', 'Europe/Bucharest').format('nice'))
//Mar 31st, 2:43am

only march overflows. error begins at 7:20pm and ends at 8:20pm.

bucharest has a dst switch at 03/25:03, may be related

There are many cases where allowing unix style formats would let this library be used in many more places than it can be today. I myself have many cases where the list of included formats do not expose nearly enough flexibility or control to get the exact format needed.

Would you consider adding a new method (or extending the current one) such as .formatUnix() or something? It could also possibly be a secondary optional package to include which will extend spacetime with the unix formatting capability.

Background
This (and the lack of i18n support) is preventing me from adopting this library over moment which I desperately want to move on from for many reasons. This looks to be the first viable competitor because of the excellent timezone support (and all of my use-cases don't need the historical accuracy!)

Exposing this functionality (even as an optional module) I am sure would be useful for many others as well in the same situation as I am. There are many cases where legacy processes or database operations require an exact, specific format.

Weeks start on different days in different regions. And some folks may have totally arbitrary week needs!

spacetime('2018-02-30').isValid() returns true. Obviously, it shouldn't

It would be nice to have basic support for translating the days and months.

While it would also be nice to include a bunch of locales ready to go, its not necessary if a method is exposed to update the strings.

Is this something you would consider, and would you humor a pull request to add this behavior if I get time to do so?

It looks like Spacetime has a bit of trouble with fractional timezones, and gets a bit confused with reading in timezones that are ahead / behind GMT. Example:

// Create a starting place (noon today GMT)
s = spacetime('2018-08-28T12:00:00Z')

// Setup some timezones to look at
let timezones = [
  {
    timezone: 'America/Toronto',  // -4h
  },
  {
    timezone: 'Asia/Muscat', // +4h
  },
  {
    timezone: 'Asia/Kathmandu', // +5h 45m
  },
  {
    timezone: 'Asia/Calcutta', // +5h 30m
  }
]

timezones = timezones.map(tz => {
  // Create a version of the above time in this timezone
  thisSpacetime = s.clone().goto(tz.timezone)
  offset = thisSpacetime.timezone().current.offset,
  nice =  thisSpacetime.format('nice')
  iso = thisSpacetime.format('iso')
  
  // Create a (hopefully identical) version of the above timezone
  interpreted = spacetime(iso)
  interpretedOffset = interpreted.epoch ? interpreted.timezone().current.offset : '',
  interpretedIso = interpreted.format('iso')
  interpretedNice = interpreted.format('nice')

  return {
    ...tz,
    offset,
    nice,
    iso,
    interpretedOffset,
    interpretedIso,
    interpretedNice
  }
})

console.table(timezones)

Outputs the following:

Issues:

1. The generated ISO timestamps appear to have the timezone backwards - for Toronto, I would expect a timestamp of "2018-08-28T08:00:00.758-04:00", not "2018-08-28T08:00:00.758+04:00"
2. ST seems to interpret all positive number timezones as negative numbers (see the interpretted timezone of Asia / Muscat differing from the original offset)
3. The generated ISO dates for Asia/Kathmandu and Asia/Calcutta is not a proper ISO timestamp, and as such can't be accepted as input to spacetime

I'm willing to chalk some of this up to my inexperience with the lib / confusion with timezones.

Hello all.

I have a method that converts UTC to a dynamic local time but testing using America/Los_Angeles the library seems to be off by one day when PST goes over to PDT (winter to summer time)

According to timeanddate.com/time/zone/usa/los-angeles the time change should occur 2018-03-11 02:00:00 but this seems to happen 2018-03-12 02:00:00 local time.

Code

// From config config.TIME.FORMAT.RAW_DATE_UNIX_LOCAL
RAW_DATE_UNIX_LOCAL: 'YYYY-MM-dd HH:mm:ss'

/**
 * Converts from UTC to naive time - timezone aware
 * @param {string} date
 */
function _dateUTCToLocal (date) {
    // Display as local time
    const s =
        spacetime(date)
        .goto(store.getters.getUser.facility.timezone)

    console.log('BEFORE', date, 'AFTER', s.format(config.TIME.FORMAT.RAW_DATE_UNIX_LOCAL))

    // Display as local time
    return s.format(config.TIME.FORMAT.RAW_DATE_UNIX_LOCAL)
}

console.log output

BEFORE 2018-03-12T07:00:00+00:00 AFTER 2018-03-11 23:00:00
BEFORE 2018-03-12T08:00:00+00:00 AFTER 2018-03-12 00:00:00
BEFORE 2018-03-12T09:00:00+00:00 AFTER 2018-03-12 01:00:00
BEFORE 2018-03-12T10:00:00+00:00 AFTER 2018-03-12 03:00:00
BEFORE 2018-03-12T11:00:00+00:00 AFTER 2018-03-12 04:00:00
BEFORE 2018-03-12T12:00:00+00:00 AFTER 2018-03-12 05:00:00

Thanks in advance. Love the project!

Pretty sure it's related to #90 feel need to document it here since it breaks tests.

As can seen from above, there was 20 days difference when running it later. (10 days diff if only minus 10 year)

Glad to fix on this one by the way.

There's this excellent family of IANA Timezone data files published on NPM now:

You can depend on everything by using the root package:
https://www.npmjs.com/package/tzdata

Or, you can pull out just the areas that you want, like:
https://www.npmjs.com/package/tzdata-asia

It would be incredibly useful if spacetime were to expose an API for initialising with arbitrary tzdata so that we could manage both the accuracy and scope (and therefore bundle size) of our applications when using spacetime.

Nice wee package, enjoying it so far!

The Timezone section of the README file should be updated: timezone().current.offset is now expressed as integer, not in minutes.

spacetime('2019-01-25T20:00:00+01:00').isBefore('2019-01-25T20:00:00+01:00') returns true, but clearly is the same date. Prob is, when milliseconds are not specified, the parser doesn't assume 0, but a random (prob taken from current date) value.

(If the env doesn't support that spec yet)

tap-spec is listed under dependencies and not developer dependencies; this module has ~3 dozen deps of its own, and adds almost 2MB to Spacetime.

Will PR to move this into dev deps!