Dates

[Cezar]

Hi Guys, ok so what was the reasoning not to implement a date datatype?

Would it make sense to have a "date" datatype which is just an alias to long so that bandicoot clients can know which fields are actually dates?

Thanks,

Cezar

[Ostap Cherkashin]

hello and sorry for a late reply.

the reason is simple: the date type was not required _so far_ :-) since a type is a set of values it felt like int and long represent sufficiently good range of values to cover dates, timestamps, etc. however your problem is more to do with tagging an attribute to understand how

to render it. there is a general case solution using the relations themselves, but the date/time types are so frequent that i feel like we need to do something about it.

i can see two options here:

1.) create a built-in type "time". though i would make it a separate type (as opposed to an alias) and allow type conversion to long, int, etc.

2.) allow type aliasing (with v5 syntax):

---

type date long

type Log { msg string, when date }

---

the problem i see here is uncontrolled proliferation of aliases and a significant impact on system interoperability.

- ostap

[Cezar Lotrean]

How about aliasing long behind the scenes and treating time as a first class citizen (datatype) in the syntax?

[Julius Chrobak]

I'd agree with option the first option, i.e. creating a new built-in type instead of an alias behind the scene. An alias could create an inconsistency in case of type conversions because the system would treat it as long but it would be a separate data type from the language perspective. There are no implicit type conversions supported in the language currently. Even the conversions between int and long is explicit. 

julius

[Cezar Lotrean]

Sounds good.

[Ostap Cherkashin]

ok, we reserved the "time" keyword in v5. "bandicoot convert" will prepend all keyword clashed with the "___" so you can easily spot the changes.

- ostap