issues

Table actions

1 row where state = "closed", type = "issue" and user = 2049051 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: created_at (date), updated_at (date), closed_at (date)

type 1

  • issue · 1 ✖

state 1

  • closed · 1 ✖

repo 1

id node_id number title user state locked assignee milestone comments created_at updated_at ▲ closed_at author_association active_lock_reason draft pull_request body reactions performed_via_github_app state_reason repo type
158518147 MDU6SXNzdWUxNTg1MTgxNDc= 869 open netCDF gives 'time' dim with 1969 change in timezone brews 2049051 closed 0     5 2016-06-04T18:46:38Z 2016-06-04T20:20:46Z 2016-06-04T19:47:39Z CONTRIBUTOR      

I'm on xarray version 0.7.2 netCDF4-python version 1.2.2 Python version via Conda: 3.5.1 |Continuum Analytics, Inc.| (default, Dec 7 2015, 11:16:01) [GCC 4.4.7 20120313 (Red Hat 4.4.7-1)]

The time dim on Datasets read in from netCDF files seems to change timezones in 1969. This is especially a pain for annual data because the bug causes annual indexes to shift by one year. I've seen this problem in reanalysis for NCEP/NCAR, Twentieth Century Reanalysis, and some reconstructed SST fields.

For example, if a read in a netCDF file. Take NCEP/NCAR Reanalysis 1 monthly mean geopotential height as an example (ftp://ftp.cdc.noaa.gov/Datasets/ncep.reanalysis.derived/pressure/hgt.mon.mean.nc ; a 278 MB file).

``` python import xarray as xr

ds = xr.open_dataset('~/Downloads/hgt.mon.mean.nc') print(ds.time) ```

The interesting part of this printed time dim is always around 1969:

... '1969-09-01T00:00:00.000000000Z', '1969-10-01T00:00:00.000000000Z', '1969-11-01T00:00:00.000000000Z', '1969-12-01T00:00:00.000000000Z', '1969-12-31T17:00:00.000000000-0700', '1970-01-31T17:00:00.000000000-0700', '1970-02-28T17:00:00.000000000-0700', ...

You can see we go from Z to-0700. It also gives me an extra measure for Dec 1969 :-\

I don't think this is a hidden calendar or datetime-like feature that I'm unaware of...? Seems like a bug with you guys or upstream.

Thanks for your help!

 
{
    "url": "https://api.github.com/repos/pydata/xarray/issues/869/reactions",
    "total_count": 1,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 1,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   completed xarray 13221727 issue

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options: 

CREATE TABLE [issues] (
   [id] INTEGER PRIMARY KEY,
   [node_id] TEXT,
   [number] INTEGER,
   [title] TEXT,
   [user] INTEGER REFERENCES [users]([id]),
   [state] TEXT,
   [locked] INTEGER,
   [assignee] INTEGER REFERENCES [users]([id]),
   [milestone] INTEGER REFERENCES [milestones]([id]),
   [comments] INTEGER,
   [created_at] TEXT,
   [updated_at] TEXT,
   [closed_at] TEXT,
   [author_association] TEXT,
   [active_lock_reason] TEXT,
   [draft] INTEGER,
   [pull_request] TEXT,
   [body] TEXT,
   [reactions] TEXT,
   [performed_via_github_app] TEXT,
   [state_reason] TEXT,
   [repo] INTEGER REFERENCES [repos]([id]),
   [type] TEXT
);
CREATE INDEX [idx_issues_repo]
    ON [issues] ([repo]);
CREATE INDEX [idx_issues_milestone]
    ON [issues] ([milestone]);
CREATE INDEX [idx_issues_assignee]
    ON [issues] ([assignee]);
CREATE INDEX [idx_issues_user]
    ON [issues] ([user]);