I want to store Time values, only time, not dates, in DataTables. Since there’s no native column type for storing Times, what would you use for storing those times?
A column of datetime with an irrelevant date? A number representing the delta? Store it as a string?
it depends what exactly those values represent…
Yes, I do exactly this for all those cases. However, my case is none of those.
I need to store a specific hour of a date (non-specific date), like ‘8:00’ or ‘23:30’.
This would then be combined with a date stored in other table, in other application.
Something like datetime.combine(apointment.date, settings.default_appointment_time).
You could use simple object column and then hold a list of integers in there. That could then easily be passed to the datetime.time init.
Something like:
[8]
[23, 30]
in the db. which could then be used as:
datetime.combine(somedate, datetime.time(*row[column])
I would store it as a text: 08:00 or 23:30.
I’d go with time_instance.isoformat() and time.fromisoformat(). They produce human-readable strings that sort correctly.
Tip: If you’re using Model Classes, you can put a @property on your model that is of type time, use the nice API from UI code, and have the getter and setter convert to and from the iso-formatted string.
yeah, the model classes make this stuff much nicer. I was attempting to come up with something that works straight from the row, but it’s not as nice.
I thought about this. Right now I don’t think I will need to sort or filter by this column, but if I did in the future, this wouldn’t be that good right? Like sorting by time or fitering times before or after noon.
I was leaning for this or storing in two columns for hour and minute, since both are easy to sort, filter and view in datatables viewer.
That’s interesting… Easy way for reading and converting.
Right now I’m delaying the implementation of Model classes since I already have a long implementation for “Model” classes and changing this would require look for a lot of code in multiple apps that could break, unfortunately for me.
Also, I was typing my response to Owen about sorting when you posted exactly my point. Are you reading my drafts??? 
Anyway, I think I’ll go with string using the isoformat approach. Thank you all for sharing your thoughts!
Not quite. If the time is for a given geographic location, then that location’s time zone (name, not offset!) may still be relevant.
Edit: example: 4pm in Munich is not 4pm in Chicago.
On this point: Model classes are 100% entirely backward compatible with the existing Data Tables API. Whatever you’re already doing, you can create a model class for the row concerned, and it won’t break anything. You can then incrementally add new API surface to it without breaking the existing users.
In general, if you’re already using a “model” class that wraps instances of a data tables row, and you’re looking to migrate, here’s what I would suggest: First, create a Model Class (won’t break anything). Then start migrating the implementation of your model features out of the wrapper and into the Model Class, piece by piece, leaving the methods and properties on the outer class forwarding to the model inside. Eventually, you can get to a point where the model has exactly the same API as the wrapper, and you can substitute one for the other. You could start by using this time property as the first step!
Having a time without date doesn’t allow to manage the daylight saving time.
I was thinking that either you manage both timezone and daylight saving time, or just plain time of the day, and daylight saving time can’t be managed without date, so my quick statement “no date → no timezone”.
I could put the time zone string in a neighboring column. Then I can look up its rules for daylight saving time – if and when I need to.
Standard Python dates include offsets, which don’t tell you which time zone rules to apply. Named time zones do.
If you needed to convert that time-of-day into your own local time, then yes, you would need to specify your specific date, and your own local time zone.
does a good job of covering the distinctions and issues.
Just a follow on this (don’t want to start a whole sub-thread on a different topic here): I know! I can just stop using rows and start using Model inside my wrapper, or even just remove the wrapper and use just the Model classes. I think most of the time anvil (or the anvilistas team) release some native (or “almost native” in case of anvil_extras) way of doing what I already do I take some time to rethink and rebuild what I already do in this new way, mostly for support and for testing (I love trying new things from anvil!). That’s what I did for layouts: I rebuild my oldest and bigger app using that used the old material design and hashrouting to layouts and routing. And it was awesome!
The thing is: I’m in the middle of something a little time-consuming and that has a deadline, so I don’t want to take risks right now and don’t have the time to delve into the Model docs (I always love to read api and implementation docs). But as soon as I can, I’ll surely migrate to Model classes, this is guaranteed!
About the timezones:
In my specific case I’m implementing right now timezones doesn’t matter, since every time informed by the user will only matter to him, in his timezone. Even if he travels to another timezone, the absolute time will still apply in the new timezone, so str will do the work.
Thinking about daylight-savings, I agree with @stefano.menci that dates will probably be important, so in that case, I would just use a datetime object, but if you think of a globally available app, timezones with just times and no dates makes sense too, as @p.colbert suggested.
Image a page that says that “the meeting occours every monday at 8:00 in Munich”. We don’t have a date, but we have a time and a timezone, so we could convert this to the local time of the user accessing the page and say “the meeting occours every monday at 8:00 in your local time”. In this case, I think saving in two columns would be the way to go, as suggested too.
At least until DST goes into/out-of effect in Munich. If your zone’s DST doesn’t change in the same way at the same time, then the conversion is valid only for specific dates.