dates and types

[David Welton]

https://github.com/ChicagoBoss/ChicagoBoss/issues/489

Any thoughts on this and my proposed fix? This is fairly urgent for us.

--
David N. Welton

http://www.welton.it/davidw/

http://www.dedasys.com/

[David Welton]

I don't mean to be a pest about this, but the 70 year old woman our
system reports as having a birthday in 2038 was a bit confused, as
were we!

The problem is pretty clear: there are various places in the code
where the code tries to make some guesses about what {X, Y, Z} is
where they are all integers. There's simply no way to tell if it's a
now() or a date() because for Erlang they are exactly the same thing.

I'm less clear on the solution, but the idea I proposed was to
transform all {X, Y, Z} dates into {{X, Y, Z}, {0, 0, 0}}. I'm not
wild about it, but am pretty much out of ideas. The only other thing
that comes to mind is explicitly tagging dates as such: {date, X, Y,
Z}.

Thanks

[can2nac]

"This is the classic "lack of types" problem where we're not sure if it's a date() or a now()."

what about calendar:valid_date()? it can distinguish date() from now()

2> calendar:valid_date(now()).

false

3> calendar:valid_date({1409,838764,643402}).

false

4> calendar:valid_date({2014,8,1}).

true

[Jesse Gumm]

The problem with calendar:valid_date is that any valid date() is also a valid now().

I'm of the opinion that the datetime() format is probably the best option.

--
Jesse Gumm
Owner, Sigma Star Systems
414.940.4866 || sigma-star.com || @jessegumm

--
You received this message because you are subscribed to the Google Groups "ChicagoBoss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chicagoboss...@googlegroups.com.
Visit this group at http://groups.google.com/group/chicagoboss.
To view this discussion on the web visit https://groups.google.com/d/msgid/chicagoboss/12ebe491-dc5b-49a5-aa77-d20e6d7ab87a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Welton]

Good idea, but you just got lucky with your 'now' result.

DateNow = {1409,1,1}.
{1409,1,1}
(gsd...@localhost.localdomain)25> calendar:now_to_local_time(DateNow).
{{2014,8,25},{22,53,21}}
(gsd...@localhost.localdomain)26> calendar:valid_date(DateNow).
true

> --
> You received this message because you are subscribed to the Google Groups
> "ChicagoBoss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to chicagoboss...@googlegroups.com.
> Visit this group at http://groups.google.com/group/chicagoboss.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/chicagoboss/12ebe491-dc5b-49a5-aa77-d20e6d7ab87a%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[can2nac]

i don't know your date ranges, but u can manually set X limit

valid_date(V={X,_,_}) when X > 1800 -> calendar:valid_date(V);

valid_date(_) -> false.

On Monday, August 25, 2014 4:06:00 PM UTC+4, David Welton wrote:

[David Welton]

Another approach might be to coordinate and unify the behavior across
CB: {X, Y, Z} is a date(), not a now(), or vice versa.

For instance, the json code I'm wrestling with expects a now(), but is
giving the wrong thing because boss_db is giving me a tuple that's
really a date.

I've got to fix this in the next day or two, though, one way or the other.

[Dmitry Polyanovsky]

Hi,

boss_db is internal part of CB, actually everything turns around it, so my believe is to go with format returned by boss_db.

--
You received this message because you are subscribed to the Google Groups "ChicagoBoss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chicagoboss...@googlegroups.com.
Visit this group at http://groups.google.com/group/chicagoboss.

To view this discussion on the web visit https://groups.google.com/d/msgid/chicagoboss/CA%2Bb9R_vQPvwS0bjkhvZZjo%3D4K2QoH1BvYO4%2Bj9Czgsxo3aMzPg%40mail.gmail.com.

[David Welton]

> boss_db is internal part of CB, actually everything turns around it, so my
> believe is to go with format returned by boss_db.

I think boss_db is more likely to return a date() than a now(), but I
could be wrong. Postgres and the epgsql driver deal mostly in
datetimes and dates.

Perhaps the solution is to fix some of the other various pieces, such
as boss_json.erl, to deal in dates unless a now() is absolutely
required. Fixing the json module ought not be too difficult.

[David Welton]

I needed to resolve this issue *today* and decided that rather than
creating special weird datetimes, it's better to have a date be a
date, and have the JSON code deal in date() values rather than now()
values, as the former are far more common in models. At least in our
code. What are others' experiences?

I opened a pull request: https://github.com/ChicagoBoss/ChicagoBoss/pull/501

In theory, now() values should not be negative:

Timestamp = timestamp()
timestamp() =
{MegaSecs :: integer() >= 0,
Secs :: integer() >= 0,
MicroSecs :: integer() >= 0}

So they're a lot less flexible than dates and datetimes in any case.

I'm happy to keep working on a solution that fits everyone's needs,
but I needed to pull the trigger on this so that our site wasn't
showing elderly people being born in 2033.

[Graeme Defty]

David, sorry not to have helped you arrive at this choice, but IMHO  this is the right way to go.

now() values, as I understand it, are principally a way to access a series of timestamps which are guaranteed monotonically increasing (and therefore unique).  It is not a value-type which should be held as 'data' (that is to say 'user' data) and so should not occur in database records, other than perhaps where a unique key is needed. Certainly in my app I use exclusively date and datetime without a now() in sight.  Having to format a now() specially if I had one would be no hardship - or at the very least, the lesser of the evils.

Cheers,

Graeme

--
You received this message because you are subscribed to the Google Groups "ChicagoBoss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chicagoboss...@googlegroups.com.
Visit this group at http://groups.google.com/group/chicagoboss.

To view this discussion on the web visit https://groups.google.com/d/msgid/chicagoboss/CA%2Bb9R_ux1isNSQyDDrUMvG8vMTZiBVtfnvpPYLirD0vyTq6m5A%40mail.gmail.com.

[Jesse Gumm]

Dates are almost certainly more regularly intended, and I'm okay with
having it use dates instead of now() format.

As for the usage of now(), the now() format is returned by both now()
and os:timestamp(), and is the only way to get subsecond accuracy (if
you need it).

The primary difference between erlang:now() and os:timestamp() is that
erlang:now() is guaranteed to be unique (on a single node), while
os:timestamp() is not. The side-effect of this is that erlang:now()
run in a very tight loop, the node's sense of time become skewed.

So erlang:now() is typically done for uniqueness, while os:timestamp()
is done to get microsecond accuracy, but both rely on the now()
format.

That said, converting from now() to datetime() is trivial
(calendar:now_to_datetime()). The reverse of this requires a bit of
work, but if you're using qdate, it's just qdate:to_date(Now).

Anyway, enough rambling from me this morning. The short of it is that
I'm okay with just assuming date() for now.

> https://groups.google.com/d/msgid/chicagoboss/CAKF5fiA-WsRWHGdnDuRu%2Buz0%3D1CMENMre-U7L9MFxoG7BddxTg%40mail.gmail.com.

>
> For more options, visit https://groups.google.com/d/optout.