Saving the date in UTC

#1

I use `$edit-date’ to set date and time. I can select a date and time and all seems to be well.

But once set, TiddlyWiki interprets the date as UTC whereas I follow UTC+0530, IST.

So, if I set the timestamp as 202111070000000 whereas I meant it to be IST, TiddlyWiki considers it as UTC and therefore, displays the timestamp to be 202111070530000.

How do I solve this problem? I want to be able to set the time in UTC. TiddlyWiki will then make the necessary timezone adjustments while displaying the time.

If this means that I will have to use some other date picker, please let me know.

At a more general level, how do you handle timestamps? Storing and displaying?

#2

Where are you getting $edit-date from?

Generally the time fields in TW want a UTC time, but will display your local time.

For my own timestamp fields, I usually use yyyy-mm-dd which is local, sortable, easy to read and write, and doesn’t cause the headaches UTC time does. I almost never require the actual time of an event.

#3

@Mark_S $edit-date is from here. I will also update my question.

I am sticking to using the standard TiddlyWiki date format to store date values to make it easy to manipulate dates.

#4

Huh, I had never noticed that.

Nothing to do with the particular plugin you are using, but rather a funky feature-creature about how TiddlyWiki operates.

When I go to TiddlyWiki.com and create a new tiddler, the creation date is 20211107153820566 when my local time is 20211107113820566.

Never been a problem in my three year experience with TiddlyWiki.

However, if one were to export a tiddler as a TID, then grab content out from there via text editor, wouldn’t that be a problem?

Or same thing, except exporting the TID to CSV to import into some other system?

#5

Modified and created dates are stored as UTC. Displayed with local time.

It’s mostly a problem with the sameday filter which promises that you can use YYYYMMDD as input. But this isn’t exactly true if put in your local date which it will see as the START of the equivalent UTC date. Or at least that’s how I’m remembering the issue.

For import/export, as long as you know what rules are being followed – the date will probably have to be adjusted to match that of the importing system anyways.

#6

A total aside: until now, I had never really put much thought into the complexity of sharing time-stamped information across time zones, “offsets”, and how some places’ offsets are different (daylight savings time.)

A short and interesting read for those interested: Time Zones Aren’t Offsets – Offsets Aren’t Time Zones.

America/Coral_Harbour is a time zone (for simplicity, I will focus only on IANA* time zones). America/Detroit is a time zone. With laws as they are now, the America/Coral_Harbour time zone has an unchanging offset of -0500, or five hours “behind” GMT, which for our purposes here matches UTC. America/Detroit changes during the year from an -0400 offset to an -0500 offset. So sometimes, the good people of Coral Harbour and the good people of Detroit have the same offset. Sometimes, they don’t.

It may not be rocket science, but I do appreciate (in a new light?) the automation any system does to figure out UTC time based on a date+time entered from any location. Pretty cool.

#7

As I recall use the UTC Date and let you local time do the work, then where ever you or your reader is they get the real time.