Converting a date from local time to UTC

#1

Folks,

I am still occasionally struggling with the tiddlywiki serial date and time stamps.

  • I am in the +11 UTC time zone, so when I convert local to UTC it should be an earlier date/time

I think I can simplify the problem as;

How do a convert a local time/date, in tiddlywiki stamp format, to UTC?

  • We can convert a UTC time stamp to local time by not including the [UTC] part in the date format.
  • We can generate a UTC time using
  • If however I want convert local time to UTC how would we do this?

Some example code.

\define tw-utc-timestamp() [UTC]YYYY0MM0DD-0hh0MM
\define tw-timestamp() YYYY0MM0DD-0hh0MM
* Now in local <<now "YYYY0MM0DD0hh0MM">>
* Now in UTC <<now "[UTC]YYYY0MM0DD0hh0MM">> for me that is yesterday
* Local time as UTC {{{ [[202312151012]format:date<tw-utc-timestamp>] }}} same as local time?
* Local time  {{{ [[202312151012]format:date<tw-timestamp>] }}} adds 11 hours?

<<now TZD>>

Gives me;
Snag_38e6bbf

  • I would think now in UTC for me would subtract 11 hours?
  • Unfortunately we don’t have the built in date maths to add and subtract the TZD

Am I missing something?, or is tiddlywiki?

Design Opportunity pass parameters to macros and procedures from a filter?
#2

The input for the format:date[...] filter is always assumed to be UTC.

Thus, in your example, with input=202312151012 and using a format that starts with [UTC], no timezone shift occurs… and when using a format that doesn’t start with [UTC], the input time is converted to localtime, resulting in a timezone shift (for you, it adds 11).

Convert created/modified field value to UTC and use it as value for HTML datatime attribute
#3

So well explained thanks Eric. It is now very obvious what I was thinking was wrong, and I can see an opportunity to improve the documentation, to place a little more emphasis on it.

  • So in an output date format we use a UTC format to “keep it as UTC” and not be localised.

Is there still a gap?

So in many ways we use [UTC] to indicate it is a UTC date, and not to localise it, where the default assumption is “it is a UTC date” (because that is what created and modified is).

  • If we do not use UTC in the date format it will localise it.

When someone uses an interactive picker to select a data and time (not using now) they would tend to think of it as a local time, even if we then convert it for storage as UTC. But in this case we have a local time, we want to change to UTC what do we do?

  • If we are unfortunate enough to have a date in local time, is there a way to convert it to [UTC] ? That is take a local time and reverse the it to UTC?
  • Basically,
    • if we have a +Hour TZD add a -Hour.
    • if we have a -Hour TZD add a +Hour.

I can see it may be possible if we go via the Unix timestamp but that is quite convoluted.

Following the current standard could we introduce [local] that would say this is a Local time, thus [local]YY0MM0DD..format:date<utc format>] would subtract/add the local time to convert it to UTC?

  • and handle day/month/year changes if needed.
  • I would imagine javascript functions can already handle this.
#4

I wonder whether it’s helpful to think of this as a mostly matter of how a date is displayed — rather than speaking of “converting” or “changing” it.

It’s only when we’re inputing a date-time string that we need to take special care to make sure that the objective/universal date-time is what’s getting entered (that is, we need tools to “convert” our intuitive-local understanding of the date-time into the universal time code / Z / nautical time which is what we need to be stored under the hood…

#5

Exactly. I think there is a gap preparing a date for storage and when it comes to display we seem to already have all bases covered.

This topic was driven by an elegant custom widget I have developed for a date picker. I was preparing to published it and demonstrate a cool code pattern, when I realised that it was not storing a user entered date in utc.

  • I expect I can convert to a unix time stamp, apply a time zone reversal, convert back to the tw serial date and store it, but all this handling is most likely unnessasary as it should be an out of the box feature and undoubtedly is already possible from within javascript and existing core code.
#6

Or maybe

`[UTC+11]YY0MM0DD..format:date<utc format>]

Where +11 can be any number that timezones support.

So we can display whatever time we want to see. A use case is if you’re collaboratively working with someone, you might want to see what time they made a change in their local time. So you’ll be able to anticipate if someone is going to be available for response or is going down for the (local) night.

Or maybe just to make your own world clock to see at a glance what time it is in several locations you correspond with.

1 Like
#7

see https://tiddlytools.com/#TiddlyTools%2FTime%2FWorldClocks

Press “select places” button,
use checkboxes to select from configured places
use “pencil” button to edit tiddler containing list of configured places
use “clone” button to create a new list from currently selected places

Lists of places are stored in tiddlers tagged with “places”, and are “data dictionary” tiddlers where the indexes are the names of locations (e.g., cities), and the values are UTC timezone offsets (i.e., -12:00 through +12:00). For example, TiddlyTools/Time/Places contains:

Honolulu:     -10:00
Anchorage:    -09:00
Vancouver:    -08:00
Seattle:      -08:00
San Francisco:-08:00
Los Angeles:  -08:00
Denver:       -07:00
Phoenix:      -07:00
Winnipeg:     -06:00
Chicago:      -06:00
New Orleans:  -06:00
Montreal:     -05:00
Toronto:      -05:00
Boston:       -05:00
New York:     -05:00
Philadelphia: -05:00
Miami:        -05:00
London:       +00:00
Rome:         +01:00
Moscow:       +03:00
New Delhi:    +05:30
Beijing:      +08:00
Perth:        +08:00
Tokyo:        +09:00
Adelaide:     +10:30
Sydney:       +11:00

Note that instead of using city names, you could use names of people who live in those locations. Thus:

Tony:   +11:00
Jeremy: +00:00
Hans:   -05:00
Eric:   -08:00

could show you current times for the people you correspond with.

-e

1 Like
#8

I’ve certainly run into similar frustrations in the past. It would be lovely to have a date-picker widget that has a timezone-offset dropdown menu (defaulting to local offset), so that we don’t have to worry about it at all.

I could imagine a feature or plugin, down the road, where any and all date/times in a wiki display according some kind of cascade condition (and where the display offers clear but unobtrusive visual cues to inspire confidence about whether/how timezone adjustments are in place).

Many folks may be happy with a 100% focus on their local time. But an astronomer might mostly require UTC (when the lunar eclipse begins/ends, time of a solar flare event). Still, perhaps they also have tiddlers for research-collaborators or observation-stations where local time matters (when the penumbra of a solar eclipse first touches Hawaii, sunrise/sunset times for ReykjavĂ­k). Meanwhile, a sleep-researcher, who is getting sleep data logs from a couple geographically separated labs, may care only about relations between circadian rhythms and local time, whatever that local time is. A cascade might go something like this:

  • First, in any tiddler, look for a utc-offset field value, and display any times within the tiddler’s body according to that offset (if it exists).
  • Else, for any tiddler tagged “global” (or whatever), display according to UTC
  • Else, for any other tiddler, display according to browser’s timezone.

For the sake of projects that care about multiple timezones, users could activate a setting to make all times display with a color-coded round icon — (+11) (Z) (–5) etc — so that it’s easy, at a glance, to confirm one’s understanding of how the time is being represented. (A well-chosen color gradient would minimize squinting to distinguish +3 vs +8, etc.)

Easier to outline a solution than to build it, of course! And perhaps there are more solution-ingredients already out there…

#9

While I was sleeping a lot of interesting ideas came out here for using time zones but most depend on being able to go from LOCAL > UTC while maintaining the ease of UTC > LOCAL.

Basicallyy we need way to selectivelyy reverse the time zone which is not more than 24hours at least for now Date conversions (XKCD)

I think my previous mention of [local] was misguided as I think it would be confusing to use, as @EricShulman pointed out above using UTC is already somewhat complicated.

  • dates are assumed to be utc

I think I will use unix time to explore this before proposing a solution but hopeful someone with javascript skills to see if there are already methods.

  • although Chat GPT may get me there faster :nerd_face:

I think the solution should be generalised to move to and from any time zone with local/utc the default.

  • the time zone can be drawn from TZD by default or provided in a literal or variable.
  • @Mark_S solution is interesting but may limit some solutions because the offset is not a variable and/or use the TZD value
  • for all the advanced time zone and date handling I cant recommend anything better than @EricShulman’s comprehensive tools.

For me I just want to be able to go both ways including local to utc in addition to utc to local which is already possible.

Post Script,

  • being able to use @EricShulman’s named world times would be nice.
  • Observation the TZD is ±0HH:0MM which can further complicate issues, and yes there are time zones with minutes, from memory 30 and 45 minutes are in use.
  • Is there a practical way to change the local timezone only within the wiki? ie not used the one received from the browser?
#10

Bump. I would like to complete this and fill the gap.

Imagin a log you import in local time how do we go from local time to utc? Or for that matter another time zone.

I am thinking how, but would like to see a core feature fill this gap.

[Edited]
I have found a way to do date maths using the TIMESTAMP or unix format. TiddlyWiki.com displaying a difference, but once again the tools we provide are incomplete, how do I get a unix time back to a TiddlyWiki time stamp?

Erics timer tools does this and more. However I want us to fill the few gaps in the core;

  • A date picker that can address local and utc times
  • Unix timestamp to tiddlywiki serial date
    • This permits date maths however simple add and subtract day/month/years would be helpful to regular users.
#11

Use format:timestamp[] (added in TW5.3.0)

  • input is a unix time value (milliseconds since 1970-01-01)
  • empty filter operand defaults to [UTC]YYYY0MM0DD0hh0mm0ss0XXX

-e

1 Like
#12

Thanks @EricShulman I just found that.

I will submit a documentation update in tiddlywiki.com DateFormat to see also “format Operator”.

Because I was returning to this after some time, I looked at the documentation and unlearned what I knew.

  • Really think we need to get your parsedate and unix operators or there equivalents in the core.
  • Edit-date may best be an addon but I have written a new custom widget for a “simple” date picker. I will share it.
  • This is the last step in this endeavour, it is amazing how long its taken, when it should be built in.