search

colinsheppard / time

A NetLogo extension that brings date/time utilities and discrete event scheduling to NetLogo
12 stars 13 forks source link

Change date format to match Excel's? #31

Closed SFRailsback closed 10 years ago

SFRailsback commented 10 years ago

time extension seems to require dates in format YYYY-m-d, whereas Excel (at least the American versions) translates all date codes into format m/d/yyyy. So if you open a .csv time-series input file in Excel, edit and save it, it will not work in NetLogo unless you remember to reformat the dates before saving it. This is annoying.

Is it feasible to change the date format used by time?

colinsheppard commented 10 years ago

It's definitely possible to make m-d-yyyy legal. It just makes me squirm since it's ambiguous wrt U.S. vs the rest of the world's convention on mm-dd vs dd-mm. One alternative would be to create a new prim which let's the user provide their own format string. Would this be any less annoying?

On Wednesday, April 23, 2014, SFRailsback notifications@github.com wrote:

time extension seems to require dates in format YYYY-m-d, whereas Excel (at least the American versions) translates all date codes into format m/d/yyyy. So if you open a .csv time-series input file in Excel, edit and save it, it will not work in NetLogo unless you remember to reformat the dates before saving it. This is annoying.

Is it feasible to change the date format used by time?

— Reply to this email directly or view it on GitHubhttps://github.com/colinsheppard/time/issues/31 .

Colin Sheppard Research Engineer, Schatz Energy Research Center colin@humboldt.edu 707.633.8633

SFRailsback commented 10 years ago

On 4/23/2014 6:13 PM, Colin Sheppard wrote:

It's definitely possible to make m-d-yyyy legal. It just makes me squirm since it's ambiguous wrt U.S. vs the rest of the world's convention on mm-dd vs dd-mm. One alternative would be to create a new prim which let's the user provide their own format string. Would this be any less annoying?

Hmm, a version/modification of ts-load that lets you specify the format would be a solution.

Steve Railsback Lang Railsback & Associates Arcata, California www.LangRailsback.com www.railsback-grimm-abm-book.com

SFRailsback commented 10 years ago

On 5/24/2014 10:19 AM, Colin Sheppard wrote:

Closed #31 https://github.com/colinsheppard/time/issues/31 via 4ef8b2d https://github.com/colinsheppard/time/commit/4ef8b2de6f78b951edc673fa04871bf40ac27989.

Cool! Thanks. (That was a major pain even with our Swarm version.)

Steve Railsback Lang Railsback & Associates Arcata, California www.LangRailsback.com www.railsback-grimm-abm-book.com

colinsheppard commented 10 years ago

yup this is a bug (from Steve):

Something is not right... I think my input format is OK, and the ts:load-with-format seems to read the data, but (a) the first time I output a time, it produces all kinds of junk, and (b) runtime error when I try to get some data from the time-series.

I will send test files separately - let me know if you don't get them.

One code (Frogs_2014-07-15.nlogo) works: it uses ts-load and an input file (ExampleSite_TimeSeriesInputs.csv) in the original date format. The second code (Frogs_2014-TestTSInputFormat.nlogo) uses input with dates in Excel's standard date format (Test_TimeSeriesInputs.csv) and ts-load-with-format.

colinsheppard commented 10 years ago

Issue has to do with which format get's used during the "copy" of a LogoTime... the copy command was expecting the default format for the date, needed to be tweaked to accommodate custom formats too.