arshaw

/*
Called towards the end of Duration::round when either:
- "relativeTo" is a ZonedDateTime
- "relativeTo" is a PlainDate
Also called towards the end of PlainDateTime/PlainDate::since/until when largestUnit > day
Also called towards the end of ZonedDateTime::since/until when largestUnit >= day

Avoids concepts of balancing/unbalancing/normalizing that the original algorithm uses,
a lot of which seems repetitive. Instead, leverages epoch-nanosecond comparisons.
Both more performant and smaller code size.

arshaw

new Temporal.ZonedDateTime(nano, timeZone, calendar)
/* instead: */ Temporal.Instant.fromEpochMilliseconds(milli)
/*          */   .toZonedDateTimeISO(timeZone)
/*    OR    */
/* instead: */ Temporal.Instant.fromEpochMilliseconds(milli)
/*          */   .toZonedDateTime({ timeZone, calendar })

zonedDateTime.epochMicroseconds
/* instead: */ zonedDateTime.epochMilliseconds

arshaw

class MyApp extends Component {

  fullCalendar = React.createRef()

  render() {
    return (
      <div>
        <button onClick={ this.handleNext }>goto next</button>
        <FullCalendar ref={ this.fullCalendar } />

arshaw

what about a gist that i dont' stoar?

arshaw

will i be notified of comemnts?

arshaw

<div class="app-card">
  <div class="app-card--title"></div>
  <div class="app-card--content"></div>
</div>

<!-- a variation -->
<div class="app-card -tall">
  <div class="app-card--title"></div>
  <div class="app-card--content"></div>
</div>

arshaw

<div class="app-card">
  <div class="app-card__title"></div>
  <div class="app-card__content"></div>
</div>

<!-- a variation -->
<div class="app-card--tall">
  <div class="app-card__title"></div>
  <div class="app-card__content"></div>
</div>

arshaw

<div class="app-card">
  <div class="app-card__title"></div>
  <div class="app-card__content"></div>
</div>

<!-- a variation -->
<div class="app-card app-card--tall">
  <div class="app-card__title"></div>
  <div class="app-card__content"></div>
</div>

arshaw

[{"id":830,"start":1262279460000,"end":1262281260,"title":"this is a long event isnt that righttt","body":"","multi":0,"allDay":false,"extension_id":2},{"id":831,"start":1262282052000,"end":1262283852,"title":"830","body":"","multi":0,"allDay":false,"extension_id":2},{"id":832,"start":1262284644000,"end":1262286444,"title":"831","body":"","multi":0,"allDay":false,"extension_id":2},{"id":833,"start":1262287236000,"end":1262289036,"title":"832","body":"","multi":0,"allDay":false,"extension_id":2},{"id":834,"start":1262289828000,"end":1262291628,"title":"833","body":"","multi":0,"allDay":false,"extension_id":2},{"id":835,"start":1262292420000,"end":1262294220,"title":"834","body":"","multi":0,"allDay":false,"extension_id":2},{"id":836,"start":1262295012000,"end":1262296812,"title":"835","body":"","multi":0,"allDay":false,"extension_id":2},{"id":837,"start":1262297604000,"end":1262299404,"title":"836","body":"","multi":0,"allDay":false,"extension_id":2},{"id":838,"start":1262300196000,"end":1262301996,"title":"83

arshaw

Proposal for a date system overhaul

The Problem

FullCalendar was initially designed without much notion of timezones. By default, it ignores timezone offsets in the dates it receives.

The original assumption was that if you received a date from Brussels, say "2013-09-01T12:00:00+02:00", which is noon, it would display as noon in every timezone.

However, FullCalendar shoehorns this value into a local date. With the same example, if you were in San Francisco, it internally stores the date as "2013-09-01T12:00:00-08:00". This is bad for two reasons: