That’s how I added SecondsSince1970.
In the past I’ve generally moved to the new releases as they came out. The change from API1 to API2 was mostly fun (NOT!) but, except for one very old app, it was worth it for me.
Now, however, I’m stuck on 2020r2.1. Since my apps are on and for Windows, I can’t move to a newer release unless/until Xojo restores the StyledTextPrinter functionality on Windows.
Why not just write some code to print the styled text yourself? You can get all the info needed from the TextArea
Wouldn’t an extension method be better than a subclass?
Care to explain why you need it ?
Any date/time I have to deal with I convert to seconds since the unix epoch (SecondsSince1970) and then store in SQLite as an integer. Makes them much easier to handle and is the right way to do it.
Yes, why ?
Because I have no intention to reinvent the wheel. So, unless / until Xojo restores the functionality or gives me something new that I absolutely must have, I’m staying where I am.
Positive thinking DONT fix bugs.
Last time I “move up”, my software broke because an undocumented behavior change that Xojo did.
Lot of time WASTED for me chasing the problem and many more waste of time for my clients to fix the problems caused by the corrupted files
What are you going to do with a date/time string like
Not, I hope, present it to the user, who may have some other idea about how they’d like to see a date/time. And for other instances, such as the Date: header in an email, the format is defined in an RFC.
A database is for storing data, not for making decisions about presenting data to the user, which should be done separately at a higher layer.
So, convert your times/dates to SecondsSince1970 and forget about storing strings in databases.
Oh and @Valdemar_De_SOUSA : Spelling “lose” as “loose” is a bug.
That is true as long as you don’t also need newer features… BTW my plan is to use API compatible code as long as possible writing most of my code in 2019.R1.1 and if I need a new feature using #if XojoVersion> X and write that part in teh newer IDE and compile there.
There are some issues with API 2, and I suspect all of the rough edged have not been found yet so I will avoid it for now as much as possible… but be bale to use new stuff if/when I need it…
So If I was in your position where I had code depending on it, I would write my own StyledTextPrinter to future proof my code as I really don’t think it would take very long.
You misunderstand the question. The question was about
“Why is storing as SecondsFrom1970 the right way rather than SecondsFrom1904”? What’s the point of using the Unix epoch?
Both types are Double; for me it is the same.
AFAIK it’s pretty much universally accepted that a datestamp is from the Unix epoch. Not sure if it conforms to some convention but you give almost any dev a number and say it’s a timestamp then they’ll add it on to 01 Jan 1970.
OK, now I see. My comment was about whether to store a date/time as a string, or as the number of seconds since some epoch. I use SecondsSince1970 because that was what I used when my app was mostly written in PHP. And we were all encouraged to use Xojo.Date and the like which had it, too. When I stopped using Text and the rest of the then new framework, is when I subclassed Date and added SecondsSince1970.
But any epoch will do.
Agree on that - string is just crazy …